Multidirectional syncronization of confidential data using distributed ledgers

ABSTRACT

The disclosed embodiments include computer-implemented processes that, using a distributed notarized ledger, constrain an ability of multiple parties to simultaneously, or near simultaneously, update or modify elements of reference data maintained within a centralized data store. For example, an apparatus may receive, from a first computing system, a request to modify reference data maintained at a second computing system. The apparatus may approve the first requested modification to the reference data based on a notarization criterion maintained within an element of a notarized distributed ledger, and perform operations that record notarization data characterizing the approved modification within an additional element of the notarized distributed ledger. The apparatus may also transmit the notarization data to the first computing system, and the notarization data causing an application program executed by the first computing system to modify local reference data in accordance with the notarization data.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of priority under 35 U.S.C. § 119(e)to prior U.S. Application No. 63/055,600, filed Jul. 23, 2020, thedisclosure of which is incorporated by reference herein to its entirety.

TECHNICAL FIELD

The disclosed embodiments generally relate to computer-implementedsystems and processes that facilitate a multidirectional synchronizationof confidential data across computing systems using distributed ledgers.

BACKGROUND

Software-as-a-service (SaaS) represents a widely adopted model forprovisioning software and applications on demand to a variety ofcorporate and institutional customers. Indeed, an increasing prevalenceand availability of cloud-based computing resources, coupled with astandardization of the Hypertext Transfer Protocol Secure (HTTPS)protocol within the web stack and an availability of lightweightintegration protocols, such as REST and SOAP, facilitate the adoptionand integration of SaaS applications across many large organizations andenterprises. Further, these SaaS applications often establish, andoperate on, local replicas of elements of reference data maintainedwithin centralized repositories of these organizations and enterprises.

SUMMARY

In some examples, an apparatus includes a memory storing instructions, acommunications interface, and at least one processor coupled to thecommunications interface and the memory. The at least one processor isconfigured to execute the instructions to receive, from a firstcomputing system via the communications interface, a first request tomodify reference data maintained at a second computing system. The atleast one processor is further configured to execute the instructions toapprove the first requested modification to the reference data based ona notarization criterion maintained within an element of a distributedledger, and perform operations that record notarization datacharacterizing the approved modification within an additional element ofthe distributed ledger. Further, the at least one processor is alsoconfigured to execute the instructions to transmit the notarization datato the first computing system via the communications interface. Thenotarization data causes an application program executed by the firstcomputing system to modify local reference data in accordance with thenotarization data.

In other examples, a computer-implemented method includes receiving,using at least one processor, a request from a first computing system tomodify reference data, the reference data being maintained at a secondcomputing system. The computer-implemented method also includes, usingthe at least one processor, approving the requested modification to thereference data based on a notarization criterion maintained within anelement of a distributed ledger, and perform operations that recordnotarization data characterizing the approved modification within anadditional element of the distributed ledger. Further, thecomputer-implemented method includes transmitting, using the at leastone processor, the notarization data to the first computing system. Thenotarization data causes an application program executed by the firstcomputing system to modify local reference data in accordance with thenotarization data.

Further, in some examples, an apparatus includes a memory storinginstructions, a communications interface, and at least one processorcoupled to the communications interface and the memory. The at least oneprocessor is configured to execute the instructions to transmit, via thecommunications interface, a request to modify an element of localreference data to a first computing system. The first computing systemperforms operations that approve the requested modification based on anotarization criterion maintained within an element of a firstdistributed ledger, and that record notarization data characterizing theapproved modification within an additional element of the firstdistributed ledger. The at least one processor is further configured toexecute the instructions to receive the notarization data from the firstcomputing system via the communications interface, and to modify aportion of the local reference data in accordance with the notarizationdata.

The details of one or more exemplary embodiments of the subject matterdescribed in this specification are set forth in the accompanyingdrawings and the description below. Other potential features, aspects,and advantages of the subject matter will become apparent from thedescription, the drawings, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A, 1B, 1C, 2A, 2B, 2C, 2D, 3A, 3B, 4A, and 4B are block diagramsillustrating portions of an exemplary computing environment, inaccordance with some exemplary embodiments.

FIGS. 5A, 5B, and 5C are flowcharts of exemplary processes forreplicating elements of reference data using notarized distributedledgers, in accordance with some exemplary embodiments.

FIGS. 6A, 6B, and 6C are flowcharts of exemplary processes fornotarizing a requested modification to elements of reference data, inaccordance with some exemplary embodiments.

Like reference numbers and designations in the various drawings indicatelike elements.

DETAILED DESCRIPTION

This specification relates to computer-implemented processes that, amongother things, establish and maintain a notarized, distributed electronicledger that records, within one or more data elements, a snapshot of a“current” state of a reference data store of an enterprise. The one ormore data elements of the notarized, distributed electronic ledger mayalso record elements of code that, when executed by one or morenetwork-connected notary computing systems, enable the one or morenotary computing systems to perform consensus-based notarizationprocesses that constrain an ability of multiple parties tosimultaneously, or near simultaneously, update or modify elements ofreference data maintained within the reference data store. Further, andbased on a successful application of these notarization processes to aproposed modification to the reference data, the one or more notarycomputing systems may perform additional consensus-based processes thatrecord a representation of the modified reference data within anadditional data element of the notarized, distributed electronic ledger,and that provision the updated reference data not only to a computingsystem that maintains the reference data store, but also to one or moreadditional computing systems within the enterprise, which may executeapplication programs that access or operate on portions of a localreplica of that reference data.

For example, the reference data store may be maintained by a computingsystem associated with, or operated by, a financial institution (e.g.,as a computing system of record), and the reference data store maycorrespond to a relational data store or electronic database thatmaintains elements of reference data characterizing one or morecustomers of the financial institution and interactions between thesecustomers and the financial institution. The executed applicationprograms that access or process the reference data may include, but arenot limited to, a Software-as-a-Service (SaaS) application that, uponexecution, causes the additional computing systems to establish a localreplica of one or more of elements of the reference data maintained bythe computing system of record. In some instances, the executed SaaSapplication may also perform operations that generate, and transmit, aproposal to modify one or more of the locally replicated elements ofreference data (e.g., based on a request received from a correspondingcustomer device), and that transmit the proposal to the computing systemof record in real-time (e.g., via a synchronous API call) or in batchedform with additional, or alternate, batched proposals during acorresponding temporal interval.

In some instances, the computing system of record may receive theproposal from the executed SaaS application, and may perform operationsthat approve, or reject, the proposal based on an application of one ormore approval criteria associated with the reference data store. Forexample, the computing system of record may perform operations thatparse the proposal update to identify an impacted element of referencedata, based on an analysis of one or more previously proposed andapproved modifications, the computing system of record may determinethat the proposal is associated with an element of reference dataunrelated to the one or more previously proposed approved updates. Assuch, the computing system of record may establish that the proposalcorresponds to, or in involved in, a unilateral update to the elementsof reference data maintained within the reference data store, and assuch, may approve the proposal and implemented the associatedmodification within the reference data store.

Through performance of certain of these processes, the computing systemof record may receive, mediate, and implement unilateral updates to oneor more elements of reference data maintained within the relational datastore, such as those generated by an application program executed at anadditional, network-connected computing system (e.g., the executed SaaSapplication described herein) or by an application program executed at acustomer device. In some instances, although effective at resolvingunilateral updates, certain of these processes may be ineffective at, orincapable of, resolving bilateral updates to a particular element ofreference data maintained within the reference data store.

By way of example, a bilateral update may involve a plurality ofdistinct, proposed modifications, additions, or updates to a particularelement of reference data maintained within the reference data store bythe computing system of record during a corresponding temporal interval.For instance, a bilateral update to a customer telephone numbermaintained within the reference data store may include, but is notlimited to, a first proposed update to the customer telephone numberreceived from an application program (e.g., a web browser, a mobileapplication, etc.) executed at the customer device, and a second, anddifferent, proposed update to the customer telephone number receivedfrom the executed SaaS application, each of which may be received withina particular temporal interval. When faced with a bilateral updateinvolving contemporaneously received modifications, updates, oradditional to a common element of reference data, certain of theseprocesses may be incapable of resolving potential conflicts between thecontemporaneous updates (e.g., to prevent multiple entities orindividuals updating the same element of reference data) and may beincapable of generating an accurate replica of the reference datamaintained in the reference data store by the computing system of recordat any given time, while maintaining an ability to reliably proposechanges to the reference data store.

Certain of the exemplary processes described herein, which establish andmaintain a notarized, distributed electronic ledger that records asnapshot of a “current” state of a reference data store, and whichenable one or more notary computing systems to perform consensus-basednotarization processes that constrain an ability of multiple parties tosimultaneously, or near simultaneously, modify or update elements ofreference data maintained within the reference data store, may beimplemented in addition to, or as an alternate to, the processesdescribed herein for resolving unilateral updates to the reference datastore. In some examples, the cryptographically secure and immutablecharacter of the notarized distributed ledger may establish an accurateand reliable replica of reference data maintained at the system andrecord, which may be provisioned to one or more additional,network-computing systems and corresponding executed applicationprograms, such as the executed SaaS application described herein, andmay establish an auditable record of a temporal evolution of eachmodification or update to the reference data maintained at the system ofrecord.

Further, through implementation of one or more of the exemplary,consensus-based notarization processes by the one or more notarycomputing systems, an executed application program, such as the SaaSapplication described herein, may generate and transmit, to thecomputing system of record, a proposed modification the elements ofreference data maintained within the reference data store withouttriggering a response to, or an immediate update of those elements ofreference data locally replicated by the executed SaaS application.Certain of these exemplary consensus-based notarization processes, whichcondition a modification to reference data maintained within thereference data store and to reference data locally replicated withinreplicated data stores on a successful notarization of that modificationby the one or more notary computing systems, may be implemented inaddition to, or as an alternate to, the unilateral update processesdescribed herein, through which the computing system of record generatesa discrete and corresponding response to each received, and approved,modification to the reference data store.

a. Exemplary Computer-Implemented Processes for Replicating ReferenceData Using Notarized Distributed Ledgers

FIGS. 1A, 1B, and 1C illustrate components of an exemplary computingenvironment 100. For example, as illustrated in FIG. 1A, environment 100may include a repository system 110, one or more notary systems 130,such as, but not limited to, notary system 132, and a local repositorysystem 172, each of which may be interconnected through one or morecommunications networks, such as communications network 102. Examples ofcommunications network 102 include, but are not limited to, a wirelesslocal area network (LAN), e.g., a “Wi-Fi” network, a network utilizingradio-frequency (RF) communication protocols, a Near Field Communication(NFC) network, a wireless Metropolitan Area Network (MAN) connectingmultiple wireless LANs, and a wide area network (WAN), e.g., theInternet.

In some examples, each of repository system 110, notary systems 130(including notary system 132), and local repository system 172 (mayrepresent a computing system that includes one or more servers andtangible, non-transitory memories storing executable code andapplication modules. Further, the one or more servers may each includeone or more processors, which may be configured to execute portions ofthe stored code or application modules to perform operations consistentwith the disclosed embodiments. Each of repository system 110, notarysystems 130 (including notary system 132), and local repository system172 may also include a communications interface, such as one or morewireless transceivers, coupled to the one or more processors foraccommodating wired or wireless internet communication with othercomputing systems and devices operating within environment 100.

In some instances, repository system 110, notary systems 130 (includingnotary system 132), and local repository system 172 may each beincorporated into a respective, discrete computing system, although inother instances, one or more of repository system 110, notary systems130 (including notary system 132), and local repository system 172 maycorrespond to a distributed computing system having multiple computingcomponents distributed across an appropriate computing network. Forexample, repository system 110 may be implemented as a distributedsystem, and may include computing components distributed acrosscommunications network 102, such as those described herein, or thoseprovided or maintained by cloud-service providers (e.g., Google Cloud™,Microsoft Azure™, etc.). The disclosed embodiments are, however, notlimited to these exemplary distributed systems, and in other instances,one or more of repository system 110, notary systems 130 (includingnotary system 132), and local repository system 172 may includecomputing components disposed within any additional or alternate numberor type of computing systems or across any appropriate network.

Repository system 110 may be associated with, or operated by a financialinstitution, and repository system 110 may maintain, within the one ormore tangible, non-transitory memories, a reference data store 112 thatincludes elements 114 of reference data characterizing one or morecustomers of the financial institution and interactions between thesecustomers and the financial institution. For example, reference datastore 112 may correspond to a relational data store or electronicdatabase, and the elements of reference data may include, but are notlimited to: (i) elements of customer profile data identifying andcharacterizing the customers (e.g., a customer name, customer address, acustomer phone number, a customer email address, demographic data,etc.); (ii) elements of customer account data identifying one or morefinancial services accounts or financial products issued to thecustomers by the financial institution; and/or (iii) elements oftransactional data identifying and characterizing one or moretransactions involving the issued financial services accounts orfinancial products. In other examples, the elements of reference datamay also include interaction data that characterize one or moreinteractions between the customers and the financial institution, suchas, but not limited to, data establishing a “do not call” list ofcustomers that elect not to receive telemarketing calls fromrepresentatives of the financial institution.

In some instances, reference data store 112 may maintain each ofreference data elements 114 in conjunction with, or association with, anidentifier of a corresponding one of the customers. For example, asillustrated in FIG. 1A, elements 114A of the reference data may beassociated with a particular customer of the financial institution, andreference data store 112 may store elements 114A in conjunction with, orin association with, a customer identifier 114B. For example, customeridentifier 114B may include, but is not limited to, a uniquealphanumeric identifier assigned to the corresponding customer by thefinancial institution (e.g., a login credential), a network address of adevice operated by the corresponding customer (e.g., an IP or a MACaddress), or an element of cryptographic data associated an applicationprogram executed at the device operated by the corresponding customer(e.g., a cryptogram associated with an executed mobile bankingapplication, etc.).

Customer identifier 114B may also include a unique, digital identifierassociated to the corresponding customer by the financial institution,e.g., upon registration within one or more digital portals or web pagesmaintained by computing systems of the financial institution, such asrepository system 110. Examples of the digital identifier may include,but are not limited to, a cryptogram, token, random number, or otherelement of cryptographic data, and in some instances, the digitalidentifier may represent a federated credential that enables thecorresponding customer to access one or more additional, or alternate,computing systems associated with or operated by the financialinstitution, either on an individual basis (e.g., through acorresponding digital portal or web page) or collectively through one ormore single sign-on (SSO) protocols. The disclosed embodiments are,however, not limited to these exemplary customer identifiers, and otherexamples, customer identifier 1146 may include any additional, oralternate, element of data that uniquely identifies the correspondingcustomer and is appropriate to reference data store 112 and torepository system 110, including combinations of the exemplary customersdescribed herein.

In other examples, one or more of reference data elements 114 mayidentify and characterize not only one or more existing customers of thefinancial institution, but also one or more prospective customers of thefinancial institution and the interactions of the prospective customerswith the financial institution. For instance, a prospective customer ofthe financial institution may elect to apply electronically for amortgage or other financial product offered by the financialinstitution, and may provide input to a corresponding device (e.g., viaan input unit) that triggers an execution of a web browser (notillustrated in FIG. 1A). The prospective customer may also provide, viathe input unit, one or more login credentials to the executed webbrowser, which may authenticate an identity of the prospective customerand enable the prospective customer to “log” into the executed webbrowser (also not illustrated in FIG. 1A). Based on a successfulauthentication of the identity of the prospective customer, the executedweb browser may establish an authenticated browser session, and mayperform operations (e.g., via JavaScript™, etc.) that generate a publickey fingerprint, such as a PKI fingerprint, associated with a publiccryptographic key of the authenticated prospective customer, thenow-authenticated browser session, or the executed web browser, e.g.,based on one or more hash-based operations on the public cryptographickey (not illustrated in FIG. 1A).

Through the authenticated browser session, the prospective customer mayaccess a web page associated with an electronic application for themortgage or other financial product, and may provide an initial portionof application data associated with the electronic application an inputto the accessed web page (e.g., via an input unit of the correspondingdevice). The prospective customer may, however, elect to defer acompletion of the electronic application until a later date, and theexecuted web browser may perform operations that cause the correspondingdevice to transmit the PKI fingerprint and the initial portion of theapplication data to one or more computing systems of the financialinstitution, such as, but not limited to, repository system 110 (alsonot illustrated in FIG. 1A). For example, repository system 110 mayreceive the PKI fingerprint and the initial portion of the applicationdata (e.g. one or more computing systems of the financial institution),and may perform operations that package the initial portion of theapplication data within reference data elements 116A, and that packagethe PKI fingerprint within prospective customer identifier 116B.

As illustrated in FIG. 1A, repository system 110 may store referencedata elements 116A within a corresponding portion of reference datastore 112, e.g., in conjunction with or in association with prospectivecustomer identifier 116B, which includes the PKI fingerprint. In someexamples, the PKI fingerprint may uniquely identify the prospectivecustomer to the financial institution, and represent a unique,browser-specific and device-specific identifier of the prospectivecustomer, and further, may represent a proof-of-possession on a singledevice, e.g., the corresponding device operated by the prospectivecustomer.

The disclosed embodiments are, however, not limited to prospectivecustomer identifiers, such as prospective customer identifier 1166, thatuniquely identify a prospective customer of the financial institutionbased on a browser- or device-specific PKI fingerprint, and inadditional, or alternate, instances, prospective customer identifier116B may also uniquely identify the prospective customer based onattribute data characterizing the potential customer's interaction witha communications network. Examples of the elements of attribute datainclude, but are not limited to, an IP address, one or more digitalcookies, a device address, or other PKI fingerprints (e.g., of differentweb browsers). The association between the prospective customer, the PKIfingerprint, and the elements of attribute data may enable the one ormore computing systems of the financial institution, such as repositorysystem 110, to associate together elements of data associated with theprospective customer, but received from different computing devices(e.g., interacting with a single network access point).

In other instances, prospective customer identifier 116B may identifythe prospective customer based on a unique, cryptographic identifier ofthe prospective customer across multiple web browsers (or otherapplication programs) executed at the corresponding device or at otherdevice operated by the prospective customer. For example, the PKIfingerprint (e.g., associated with the corresponding publiccryptographic key associated with the executed web browser) mayrepresent a browser-specific, proof-of-possession for the prospectivecustomer. In some instances, to facilitate an identification of theprospective customer across multiple web browsers executed by thecorresponding device, prospective customer identifier 1166 may include asplit portion of the public cryptographic key associated with theprospective customer, which may be generated through an application ofone or more key splitting algorithms to the public cryptographic keyassociated with executed web browser (e.g., by the one or more computingsystems of the financial institution, including repository system 110,or by the corresponding device). The split portion of the publiccryptographic key may, for example, be shared among each of the webbrowsers executed at the corresponding device, and may uniquely identifythe prospective customer across the multiple web browsers.

The disclosed embodiments are, however, not limited to these exemplaryelements of reference data and associated customer identifiers. In otherinstances, reference data store 112 may maintain any additional, oralternate, elements of reference data that identify or characterizepast, current, and prospective customers of the financial institutionand additionally, or alternatively, interactions between the financialinstitution and one or more of the past, current, and prospectivecustomers. Further, and as described herein, each of the elements ofreference data may be associated with, linked to, or stored inconjunction with a customer identifier that unique identifies each ofthe corresponding past, current, and prospective customers and isappropriate to a prior, current, or prospective relationship between thefinancial institution and the corresponding past, current, andprospective customer, such as, but not limited to, the exemplarycustomer identifiers described herein.

Referring back to FIG. 1A, and as described herein, repository system110 may also maintain, within the one or more tangible, non-transitorymemories, one or more elements of executable code executable applicationprograms, or application modules, such as executable replication engine118. In some instances, when executed by the one or more processors ofrepository system 110, replication engine 118 may perform operationsthat, in response to a detected occurrence of a replication event, parsereference data store 112 and generate one or more elements of statusdata 120 representative of a composition of reference data store 112during a particular temporal interval, e.g., a “snapshot” of thecomposition of reference data store 112 during a current temporalinterval. As described herein, status data 120 may include all, or aselected portion of the elements of reference data and associatedcustomer identifiers maintained within reference data store 112 (e.g.,reference data elements 114A and customer identifier 114B, referencedata element 116A and customer identifier 116B, etc.). Additionally, oralternatively, status data 120 may also include a hash valuerepresentative of all, or a selected portion, of the reference dataelements and associated customer identifiers maintained within referencedata store 112, which may be computed by executed replication engine 118through an application of a cryptographic or non-cryptographic hashfunction to all, or the selected portion, of the reference data elementsand associated customer identifiers.

Further, examples of the replication event may include, but are notlimited to, a temporal event that triggers the replication of all, or asubset, of the reference data elements and associated customeridentifiers within reference data store 112 at regular, predeterminedtemporal intervals (e.g., upon expiration of a predetermined temporalinterval since a prior replication of reference data store 112), or anetwork-based event that triggers the replication of all, or a subset,of the reference data elements and associated customer identifierswithin reference data store 112 in response to a detection of one ormore additional network-connected computing devices or systems operatingwithin environment 100. Additionally, in some examples, the replicationevent may also include a receipt, by repository system 110, of data fromone or more additional computing systems or devices within environment100 (e.g., local repository system 172) that requests a replication ofreference data elements 114. The disclosed embodiments are, however, notlimited to these exemplary replication events, and in other examples,the replication event may include any additional, or alternate eventsthat would be appropriate to reference data store 112, the discreteelements of reference data, or any of the computing systems withinenvironment 100 that access or maintained the replicated reference dataelements, such as local repository system 172.

Executed replication engine 118 may perform operations that detect theoccurrence of the replication event (e.g., the temporal replicationevent, the network-based replication event, etc.), and may performoperations that access reference data store 112, extract all, or aselected portion, of the reference data elements and associated customeridentifiers, and package the extracted reference data elements andassociated customer identifiers into corresponding portions of statusdata 120. Further, although not illustrated in FIG. 1A, status data 120may also include one or more cryptographic or non-cryptographicrepresentations of the reference data elements and associated customeridentifiers, such as, but not limited to, the cryptographic ornon-cryptographic hash values described herein.

In some examples, executed replication engine 118 may perform additionaloperations that generate a replication request 122 that include statusdata 120, temporal data 124, and one or more unique identifiers 126 ofrepository system 110 or executed replication engine 118. As describedherein, status data 120, and the corresponding reference data elementsand associated customer identifiers, may reflect a current snapshot ofthe composition of reference data store 112 at a particular time ordate, and temporal data 124 may specify the particular time or datecharacterizing the current snapshot of reference data store 112represented by status data 120. Further, identifiers 126 may include,but are not limited to, a network address of repository system 110(e.g., an IP address, a MAC address, etc.), a cryptogram or otherelement of cryptographic data associated with executed replicationengine 118, or any combinations thereof.

Additionally, although not illustrated in FIG. 1A, executed replicationengine 118 may also perform operations that encrypt one or more elementsof replication request 122 (e.g., status data 120, temporal data 124,and/or identifiers 126) using, for example, a public cryptographic keyassociated with one or more of the network-connected computing systemsoperating within environment 100, such as, but not limited to, notarysystems 130. Executed replication engine 118 may also generate and applya digital signature 128 to replication request 122 (e.g., in encryptedor unencrypted form) using a private cryptographic key 127 associatedwith repository system 110 or executed replication engine 118. Forexample, executed replication engine 118 may generate digital signature128 based on application of a digital signature algorithm or scheme toone or more portions of replication request 122 and to privatecryptographic key 127. Further, as illustrated in FIG. 1A, executedreplication engine 118 may perform operations that cause repositorysystem 110 to broadcast replication request 122 (e.g., in encrypted orunencrypted form), digital signature 128, and a public key certificate129 associated with repository system 110 or executed replication engine118 (which includes a corresponding public cryptographic key 129A)across network 102 to one or more of notary systems 130, includingnotary system 132.

Referring to FIG. 1B. a programmatic interface established andmaintained by each of the one or more of notary systems 130, such as anapplication programming interface (API) 133 of notary system 132, mayreceive replication request 122 (e.g., in encrypted or unencryptedform), digital signature 128, and a public key certificate 129 fromrepository system 110, and may route replication request 122, digitalsignature 128, and a public key certificate 129 to one or more executedapplication programs, such a verification and consent engine 134. Whenexecuted by the one or more processors of notary system 132 (and eachadditional or alternate one of notary systems 130), verification andconsent engine 134 may perform operations that validate digitalsignature 128 using public cryptographic key 129A. Based on a successfulvalidation of digital signature 128, executed verification and consentengine 134 may authenticate an identity of repository system 110 orreplication engine 118, and further, establish an integrity of the datamaintained within replication request 122. Further, in some instances, asuccessful validation of digital signature 128 by executed verificationand consent engine 134 may be indicative of an approval, of a consent,of executed replication engine 118 (and as such, of repository system110, which may operate as a computing system of record) to thereplication of the current snapshot of reference data store 112.

If, for example, executed verification and consent engine 134 wereunable to validate digital signature 128, executed verification andconsent engine 134 may perform operations (not illustrated in FIG. 1B)that cause notary system 132 (and additional or alternate ones of notarysystems 130) to generate and transmit an error message characterizingthe failed validation of digital signature 128 across network 102 torepository system 110. Notary system 132 (and additional or alternateones of notary systems 130) may also discard replication request 122,digital signature 128, and public key certificate 129.

In other examples, and based on the successful validation of digitalsignature 128, executed verification and consent engine 134 may performoperations that store replication request 122 within a portion one ormore tangible, non-tangible memories, e.g., within a portion of notarydata store 136. As described herein, replication request 122 may includestatus data 120 (e.g., which includes all, or a selected portion, of thereference data elements and associated customer identifiers maintainedwithin reference data store 112 of repository system 110), temporal data124 (e.g., which specifies the particular data and time characterizingthe current snapshot of reference data store 112 represented by statusdata 120), and one or more unique identifiers 126 of repository system110 or executed replication engine 118. Further, in some instances, allor a selected portion of replication request 122 may be encrypted, andexecuted verification and consent engine 134 may perform operations thataccess a private cryptographic key 137 associated with the one or moreof notary systems 130 (e.g., as maintained within notary data store136), and that decrypt the encrypted portions of replication request 122using private cryptographic key 137 and store the now-decrypted portionsof replication request 122 within notary data store 136.

Further, as illustrated in FIG. 1B, executed verification and consentengine 134 may provide replication request 122 (e.g., in unencryptedform) as an input to a block generation engine 138 of notary system 132.In some instances, and upon execution by the one or more processors ofnotary system 132 that generate an element 140 of a notarizeddistributed ledger 142 that includes all, or a selected portion, ofreplication request 122. By way of example, notarized distributed ledger142 may correspond to a cryptographically secure, immutable, andpermissioned distributed electronic ledger (such as, but not limited to,a blockchain ledger) established and maintained through animplementation of one or more consensus-based processes by all, or asubset, of notary systems 130, including notary system 132. Thedisclosed embodiments are, however, not limited to these exemplarydistributed-ledger data structures, and in other instances, notarizeddistributed ledger 142 may correspond to any additional, or alternate,permissioned, public, or private distributed electronic ledger havingelements that include, or record, data representative of a currentsnapshot of reference data store 112 and any approved and notarizedmodifications to reference data store by one or more computing systemsor devices operating within environment 100.

In some instances, element 140 may include (e.g., may “record”) all or aselected portion of status data 120, and as such, may record one or moreof the actual elements of reference maintained within reference datastore 112 and the corresponding customer identifiers that collectivelyestablish the current “snapshot” of reference data store 112. In otherinstances, element 140 may also record a representation of the elementsof reference maintained within reference data store 112 and thecorresponding customer identifiers, and examples of the recordedrepresentation may include, but are not limited to, a cryptographic ornon-cryptographic hash value generated by executed block generationengine 138 through an application of a corresponding cryptographic ornon-cryptographic hash algorithm or all, or a selected subset, of theactual, elements of reference data maintained within status data 120.Further, and as illustrated in FIG. 1A, element 140 may record temporaldata 124, which may specify the particular time or date characterizingthe current snapshot, and one or more of identifiers 126 of repositorysystem 110, as described herein.

Executed block generation engine 138 (and the block generation engineexecuted by additional ones of notary systems 130) may also performoperations that generate and apply a digital signature 144 to therecorded portion of status data 120 (and/or the cryptographic ornon-cryptographic representation of the portion of status data 120),temporal data 124, and identifiers 126. For example, executed blockgeneration engine 138 may generate digital signature 144 based on anapplication of a digital signature algorithm or scheme to the recordedportion of status data 120 (and/or the cryptographic ornon-cryptographic representation of the portion of status data 120),temporal data 124, identifiers 126, and to private cryptographic key137. Further, executed block generation engine 138 may generate a hashvalue 146 based on an application of one or more appropriate hashalgorithms to status data 120 (and/or the cryptographic ornon-cryptographic representation of the portion of status data 120),temporal data 124, identifiers 126, and digital signature 144 (and insome instances, to other elements of notarized distributed ledger 142,such as a hash value representative included within a previouslyrecorded element of notarized distributed ledger 142). Executed blockgeneration engine 138 may package digital signature 144 and hash value146 into corresponding portions of element 140, e.g., in conjunctionwith the portion of status data 120 (and/or the cryptographic ornon-cryptographic representation of the portion of status data 120),temporal data 124, and identifiers 126.

Notary system 132 (and each additional or alternate one of notarysystems 130) may perform operations that append element 140 to a priorversion of the notarized distributed ledger to generate a latest,longest version of that notarized distributed ledger, e.g., notarizeddistributed ledger 142, that reflects the current composition, and assuch, the current snapshot, of reference data store 112 maintained atrepository system 110. In other examples, element 140 may correspond toan initial element, e.g., a “genesis” block, of a new notarizeddistributed ledger, e.g., notarized distributed ledger 142, that notonly establishes the current composition, and as such, the currentsnapshot, of reference data store 112, but also provides an immutable,cryptographically secure, and temporally evolving record of allmodifications to the elements of reference data maintained within thereference data store 112, e.g., modifications initiated at repositorysystem 110 or modifications proposed by one or more additional computingsystems operating within environment 100, such as local repositorysystem 172.

In some instances, notary system 132 (and each additional or alternateone of notary systems 130) may perform additional operations thatgenerate and assign an index 148 to element 140, and that incorporateindex 148 within a corresponding portion of element 140. Index 148 may,for example, include a positional identifier (e.g., a “block number”)that specifies a sequential position of element 140 relative to theexisting, prior elements of notarized distributed ledger 142, oralternatively, that specifies an initial position of element 140 withinnotarized distributed ledger 142, e.g., as the genesis block. Theseadditional operations may, for example, be established through adistributed consensus among additional ones of notary systems 130, andmay include, but are not limited to, a calculation of an appropriateproof-of-work or proof-of-stake by a distributed consensus engine 149executed at notary system 132 prior to a calculation of correspondingproofs-of-work or proofs-of-stake by others of notary systems 130. Incertain aspects, notary system 132 may broadcast evidence of thecalculated proof-of-work or proof-of-stake to one or more additionalones of notary systems 130 across network 102 (not illustrated in FIG.1A). Notary system 132 may also broadcast notarized distributed ledger142, which represents the latest, longest version of the notarizeddistributed ledger, across network 102 to the additional ones of notarysystems 130 operating within environment 100.

Further, as illustrated in FIG. 1A, notarized distributed ledger 142 mayalso include one or more additional elements, such as smart contractelements 150, that record code or software instructions, such asdistributed notarization module 152, and one or more elements ofsupporting data, such as notarization criteria 154. In some examples,the recorded code or software instruction, including distributednotarization module 152, may establish collectively a distributed smartcontract, e.g., a distributed “notarization” contract. Further, whenexecuted by the one or more processors of notary system 132 (and by oneor more processors of the other ones of notary systems 130), therecorded code or software instructions, including distributednotarization module 152, may cause notary system 132 (and the other onesof notary systems 130) to perform notarization processes that constrainan ability of multiple parties to simultaneously, or nearsimultaneously, propose modifications or updates to the elements ofreference data maintained within reference data store 112 in accordancewith notarization criteria 154.

Notary system 132 (and additional, or alternate ones of notary systems130) may also perform one or more of the exemplary processes toprovision all or a selected portion of the replication request 122,which include elements of reference data (e.g., as maintained in statusdata 120) and temporal data 124 that collectively establish the current“snapshot” of reference data store 112 recorded onto or included withinelement 140 of notarized distributed ledger 142, to one or moreadditional computing systems operating within environment 100 permittedto operate on the elements of reference data maintained within referencedata store 112, such as, but not limited to, local repository system172. For example, local repository system 172, may execute aSoftware-as-a-Service (SaaS) application 174, and upon execution, SaaSapplication 174 may cause local repository system 172 to generate one ormore elements of locally replicated reference data based on theprovisioned portions of replication request 122, e.g., to establish a“local” snapshot of the composition of reference data store 112 at theparticular time and date specified by temporal data 124.

Referring to FIG. 1C, a provisioning engine 156 executed by the one ormore processors of notary system 132 (and additional, or alternate onesof notary systems 130) may access notary data store 136 (e.g., asmaintained within the one or more tangible, non-transitory memories),and may perform operations that extract replication request 122 fromaccessed notary data store 136. As described herein, replication requestincludes status data 120, temporal data 124, and identifiers 126 ofrepository system 110 or executed replication engine 118. In someinstances, executed provisioning engine 156 may perform operations thatprocess replication request 122 to obtain all, or a selected portion, ofstatus data 120, temporal data 124, and identifiers 126, and thatpackage the obtained portions of status data 120, temporal data 124, andidentifiers 126 within corresponding portions of replication data 158.

In some instances, executed provisioning engine 156 may performoperations that encrypt replication data 158 using a publiccryptographic key 160 associated with SaaS application 174 executed atlocal repository system 172. Executed provisioning engine 156 may alsogenerate and apply a digital signature 162 to encrypted replication data158 using private cryptographic key 137. Further, as illustrated in FIG.1C, executed provisioning engine 156 may perform operations that causenotary system 132 (and additional, or alternate, ones of notary systems130) to transmit encrypted replication data 158, digital signature 162,and a public key certificate 164 associated with notary system 132(which includes a corresponding public cryptographic key 166) acrossnetwork 102 to one or more additional computing systems that executeapplication programs permitted by repository system 110 to operate onthe elements of reference data maintained within reference data store112, such as local repository system 172.

As illustrated in FIG. 1C, a programmatic interface established andmaintained by local repository system 172, such as an applicationprogramming interface (API) 176 associated with executed SaaSapplication 174, may receive encrypted replication data 158, digitalsignature 162, and public key certificate 164 (which includescorresponding public cryptographic key 166), and may route encryptedreplication data 158, digital signature 162, and public key certificate164 to executed SaaS application 174. In some instances, a verificationand consent module 178 of executed SaaS application 174 may receiveencrypted replication data 158, digital signature 162, and public keycertificate 164, and may perform operations that obtain publiccryptographic key 166 from public key certificate 164, and that validatedigital signature 162 using public cryptographic key 166.

If, for example, executed verification and consent module 178 wereunable to validate digital signature 128, executed verification andconsent module 178 may perform operations (not illustrated in FIG. 1B)that cause local repository system 172 to discard encrypted replicationdata 158, digital signature 162, and public key certificate 164. Inother examples, and based on the successful validation of digitalsignature 162, executed verification and consent module 178 may verifythe integrity of encrypted replication data 158 and may establish thatnotary system 132 (and executed provisioning engine 156) represents avalid, trusted source for encrypted replication data 158. Executedverification and consent module 178 may perform operations that access aprivate cryptographic key 180 associated with executed SaaS application174 (e.g., as maintained within the one or more tangible, non-transitorymemories of local repository system 172), and that decrypt encryptedreplication data 158 using private cryptographic key 180. Further, asillustrated in FIG. 1C, executed verification and consent module 178 mayprovide decrypted replication data 158 as an input to a localreplication module 182 of executed SaaS application 174, which mayperform operations that store decrypted replication data 158 within aportion of a replicated data store 184.

In some examples, through a storage of replicated reference data 186within replicated data store 184, executed SaaS application 174 mayestablish a local replica of the elements of reference data maintainedwithin reference data store 112 at repository system 110, e.g., thesystem of record for the elements of reference data. Further, andthrough the storage of replicated reference data 186 in conjunction withtemporal data 124, certain of the exemplary processes described hereinmay enable executed SaaS application 174 to establish that replicatedreference data 186 corresponds to, or remains, a current snapshot of theelements of reference data maintained at repository system 110 withinreference data store 112.

Further, as illustrated in FIG. 1C, executed local replication module182 may provide replicated reference data 186 and temporal data 124 asinputs to a local block generation module 192 of executed SaaSapplication 174, which may perform operations that generate anadditional element 193 (e.g., an additional ledger block) of a locallymaintained distributed ledger, such as local distributed ledger 190. Insome instances, additional elements 193 may include all, or a selectedpotion, of replicated reference data 186, and may also include temporaldata 124, which specifies the time or date characterizing the currentsnapshot of reference data store 112 represented by replicated referencedata 186. In other instances, executed block generation module 192 maycompute a cryptographic or non-cryptographic hash value representativeof all, or a selected portion, of the reference data elements maintainedin replicated reference data 186, and element 193 may include thecomputed hash value in additional to, or as an alternate to, replicatedreference data 186.

Although not illustrated in FIG. 1C, executed local block generationmodule 192 may perform any of the exemplary processes described hereinto: generate an additional digital signature based on an application ofa digital signature algorithm or scheme to replicated reference data 186(and/or the cryptographic or non-cryptographic representation of theportion of status data 120), temporal data 124, and to privatecryptographic key 180; and to compute an additional hash value based onan application of one or more appropriate hash algorithms to replicatedreference data 186 (and/or the cryptographic or non-cryptographicrepresentation of the portion of status data 120), temporal data 124,and the additional digital signature (and in some instances, to dataassociated with other elements of local distributed ledger 190, such asa hash value representative of a previously recorded element of localdistributed ledger 190). Executed local block generation module 192 maypackage the additional digital signature and the additional hash valueinto corresponding portions of element 193, e.g., in conjunction withthe portion of replicated reference data 186 (and/or the cryptographicor non-cryptographic representation of the portion of status data 120)and temporal data 124.

In some instances, executed local block generation module 192 may appendelement 193 to local distributed ledger 190, e.g., to generate a latest,longest version of the immutable, cryptographically secure, localdistributed ledger, and executed local block generation module 192 maystore local distributed ledger 190 within a portion of the one or moretangible, non-transitory memories of local repository system 172, e.g.,within local ledger data store 194. In other instances, not illustratedin FIG. 1C, executed SaaS application 174 may cause local repositorysystem additional operations that append element 193 to localdistributed ledger 190 and generate a positional identifier that (e.g.,a “block number”) that specifies a sequential position of element 193within local distributed ledger 190, e.g., using any of the exemplaryconsensus-based processes described herein.

b. Exemplary, Computer-Implemented Processes for Modifying ReferenceData Using Notarized Distributed Ledgers

In some examples, a notarized, distributed electronic ledger, such asnotarized distributed ledger 142 established and maintained via adistributed consensus establish between notary systems 130, may includeone or more discrete elements, such as element 140, that include (e.g.,“record”) data representative of a composition of reference data store112 during a particular temporal interval, e.g., a “snapshot” of thecomposition of reference data store 112 during a current temporalinterval. Further, and as described herein, the discrete elements ofnotarized distributed ledger 142 may also record code or applicationmodules (e.g., distributed notarization module 152 of FIG. 1A) that,when executed by the notary systems 130, enable notary systems 130(including notary system 132) to perform one or more of the exemplary,consensus-based notarization processes described herein, which constrainan ability of multiple parties to simultaneously (or nearsimultaneously) propose updates to the elements of reference datamaintained at the system of record (e.g., within reference data store112 of repository system 110) and replicated across one or moreadditional computing systems operating within environment 100 (e.g.,within replicated data store 184.

Further, and based on a successful application of these notarizationprocesses to a proposed modification to an element of the reference data(e.g., as proposed by repository system 110 or by local repositorysystem 172), one or more of notary systems 130 may perform additional ofthe exemplary, consensus-based notarization processes described hereinto record information representative of modified element of referencedata (e.g., the actual modified reference data element and/or arepresentative hash value) within an additional element of notarizeddistributed ledger 142. In some instances, and responsive to therecordation of the information representative of the updated or modifiedelement of reference data onto notarized distributed ledger 142, certainof the exemplary, consensus-based notarization processes describedherein may provision the modified element of reference data to not onlyrepository system 110 (e.g., the system of record), but also toapplication programs executed by local repository system 172, e.g., SaaSapplication 174.

Referring to FIG. 2A, environment 100 may also include one or morecomputing devices, such as client device 202, interconnected withrepository system 110 and local repository system 172, across one ormore communications networks, such as communications network 102described herein. In some instances, client device 202 may include oneor more tangible, non-transitory memories that store data and/orsoftware instructions and one or more processors configured to executethe software instructions. Client device 202 may also include acommunications interface, such as one or more wireless transceivers,coupled to the one or more processors for accommodating wired orwireless internet communication with the one or more of the computingsystems operating within environment 100.

Client device 202 may also include a display unit 203A coupled to theone or more processors and configured to present interface elements touser 201, and one or more additional input units, such as input unit203B, coupled to the one or more processors and configured to receiveinput from user 201. By way of example, display unit 203A may include,but is not limited to, an LCD display, a TFT display, and OLED display,or other appropriate type of display unit, and input unit 203B mayinclude, but is not limited to, a keypad, keyboard, touchscreen,fingerprint scanner, stylus, or any other appropriate type of inputunit. Further, in some examples, the functionalities of display unit203A and input unit 203B may be combined into a single device, such as apressure-sensitive touchscreen display unit that can present interfaceelements and can detect an input from user 201 via a physical touch.

As described herein, client device 202 may be associated with oroperated by a user, such as user 201. By way of example, user 201 mayrepresent an existing customer of the financial institution associatedwith repository system 110, and may hold one or more one or morefinancial products or financial services accounts issued by thatfinancial institution (e.g., a deposit account, a credit card account,etc.). In other examples, user 201 may correspond to a prospectivecustomer of the financial institution (e.g., associated with a pendingor partially completed application for one or more financial products orfinancial services accounts) or a prior customer of the financialinstitution (e.g., associated with one or more inactive financialproducts or closed financial services accounts).

Further, examples of client device 202 may include, but are not limitedto, a smart phone, a mobile phone, a tablet computer, a laptop computer,a notebook computer, a hand-held computer, a personal digital assistant,a portable navigation device, a wearable computing device (e.g., a smartwatch, a wearable activity monitor, wearable smart jewelry, and glassesand other optical devices that include optical head-mounted displays(OHMDs), an embedded computing device (e.g., in communication with asmart textile or electronic fabric), and any other type of computingdevice that may be configured to store data and software instructions,execute software instructions to perform one or more of the exemplaryprocesses described herein. In some instances, client device 202 mayalso establish communications with one or more additional computingsystems or devices operating within environment 100 across a wired orwireless communications channel, e.g., via the communications interfaceusing any appropriate communications protocol.

The stored software instructions may include one or more applicationprograms, one or more application modules, or other code executable bythe one or more processors of client device 202. For instance, clientdevice 202 may store, within the one or more tangible, non-transitorymemories, one or more executable mobile applications, such as anexecutable mobile banking application 204 associated with the financialinstitution. In some examples, when executed by the one or moreprocessors of client device 202, executed mobile banking application 204may cause client device 202 to establish a secure, programmatic channelof communications with repository system 110 across network 102, and togenerate, and render for presentation via display unit 203A, a digitalinterface 206 having interface elements that enable user 201 to access,interact with, or modify or update one or more confidential elements ofcustomer-specific reference data maintained by repository system 110within reference data store 112.

Further, although not illustrated in FIG. 2A, client device 202 may alsostore, within the one or more tangible, non-transitory memories, one ormore executable web browsers and one or more additional mobileapplications associate with, or provisioned by other computing systemsoperating within environment 100 or with application programs executedby these other computing systems, such as SaaS application 174 executedby local repository system 172. For example, upon execution by the oneor more processors, the executed web browser may present, within digitalinterface 206, one or more web pages having corresponding interfaceelements that enable user 201 to access, interact with, or modify theone or more elements of reference data maintained within reference datastore 112. Additionally, in some examples, the executed web browser mayalso perform any of the exemplary processes described herein to generateone or more unique cryptographic identifiers of user 201 (and othercurrent, prospective, or prior customers of the financial institution),such as, but not limited to, a browser-specific PKI fingerprintassociated with a public cryptographic key of user 201, and a splitportion of the public cryptographic key associated with user 201 whichmay be generated through an application of one or more key splittingalgorithms to the public cryptographic key by the executed web browser.

In some instances, to facilitate a modification to the reference datamaintained within reference data store 112, user 201 may provide inputto client device 202 (e.g., via input unit 203B) that requests anexecution of mobile banking application 204. Upon execution by the oneor more processors of client device 202, executed mobile bankingapplication 204 may perform operations that initiate an authenticationprocess, and may generate and present one or more interface elementswithin digital interface 206 (not illustrated in FIG. 2A) that promptuser 201 to provide one or more authentication credentials as inputs toclient device 202. The one or more authentication credentials mayinclude, but are not limited to, an alphanumeric identifier assigned touser 201 by the financial institution, a corresponding password, or oneor more biometric credentials, such as a fingerprint scan or a facialimage.

In other instances, the initiated authentication process may beassociated with, or implemented in accordance with, one or more singlesign-on (SSO) protocols, and the one or more authentication credentialsmay a unique, digital identifier assigned to user 201 by the financialinstitution, e.g., upon registration within one or more digital portalsor web pages maintained by computing systems of the financialinstitution. Examples of the digital identifier may include, but are notlimited to, a cryptogram, token, random number, or other element ofcryptographic data, and in some instances, the digital identifier mayrepresent a federated credential that enables user 201 to access one ormore additional, or alternate, computing systems associated with oroperated by the financial institution, either on an individual basis(e.g., through a corresponding digital portal or web page) orcollectively through one or more single sign-on (SSO) protocols. Thedisclosed embodiments are, however, not limited to these exemplaryauthentication credentials, and other examples, customer identifier 114Bmay include any additional, or alternate, element of data that uniquelyidentifies user 201 and is appropriate to the financial institution,including combinations of the exemplary customers described herein.

Based on a successful outcome of the authentication process, executedmobile banking application 204 may perform operations that cause clientdevice 202 to establish a secure, programmatic channel of communicationswith repository system 110, and further, may generate and present,within digital interface 206, additional interface elements that enableuser 201 to view, and interact with, and request a modification to thereference data maintained within reference data store 112 at repositorysystem 110. For example, digital interface 206 may include interfaceelements 208A, which identify a current telephone number associated withuser 201 and maintained within reference data store 112 (e.g.,“5551234567”), fillable text box 208B, and additional interface elements208C, which prompt user 201 to enter an updated or modified phone numberwithin fillable text box 208B. Further, and by way of example, digitalinterface 206 may also include interface element 208D, which uponselection by user 201, confirms a consent of user 201 to themodification of the customer phone number, and requests a submission ofthe requested modification to repository system 110. The disclosedembodiments are, however, not limited to these exemplary interfaceelements, and in other instances, executed mobile banking application204 present any additional, or alternate, number or type of interfaceelements within digital interface 206 that would be appropriate to thereceived elements of reference data and that would facilitatecorresponding modifications to the received elements of reference data.

As illustrated in FIG. 2A, user 201 may provide, via input unit 203B ofclient device 202, input 210 to digital interface 206 that specifies theupdated phone number of user 201 (e.g., an input of “5559876543” withinfillable text box 208B), and that confirms the consent of user 201 tothe update and requests the submission of the updated phone number torepository system 110 (e.g., responsive to a selection of selectableinterface element 208D). In some instances, and in addition to, or as analternate to, processes that confirm the consent of user 201 based onthe selection of interface element 208D, executed mobile bankingapplication 204 may perform additional operations (not illustrated inFIG. 2A) that present further interface elements within digitalinterface 206 prompting user 201 to consent affirmatively to the updateto the phone number, e.g., based on a re-entry of a password of user 201and/or based on a successful completion of one or more in-band orout-of-band challenge processes. Input unit 203B may receive input 210,and may route corresponding elements of input data 212, which includesall or a selected portion of input 210, to executed mobile bankingapplication 204. For example, input data 212 may include, but is notlimited to, data that identifies the element of reference data subjectto modification by user 201, such as element identifier 214 associatedwith the customer's phone number within reference data store 112, alongmodification data 216 that specifies the requested modification, (e.g.,the updated phone number “555-987-6543”).

In some instances, executed mobile banking application 204 may receiveinput data 212, which includes element identifier 214 and modificationdata 216, and may load, from the one or more tangible, non-transitorymemories, at least one of the authentication credentials associated withuser 201, such as customer identifier 218. Further, and responsive toinput data 12, executed mobile banking application 204 may performoperations that generate a request 220 to modify reference data store112, and may package customer identifier 218, element identifier 214,and modification data 216 within corresponding portions of request 220.

Further, executed mobile banking application 204 may also performoperations that generate and apply a customer-specific digital signature222 to request 220, which includes customer identifier 218, elementidentifier 214, and modification data 216, using a private cryptographickey 224 associated with executed mobile banking application 204 orclient device 202, e.g., as maintained within the one or more tangible,non-transitory memories of client device 202. For example, executedmobile banking application 204 may generate digital signature 222 basedon application of a digital signature algorithm or scheme to one or moreportions of request 220 and to private cryptographic key 224, and mayperform operations that cause client device 202 to transmit request 220,applied digital signature 222, and a public key certificate 226associated with executed mobile banking application 204 or client device202 (which includes a corresponding public cryptographic key 228) acrossnetwork 102 to repository system 110. Further, in some instances (notillustrated in FIG. 2A), executed mobile banking application 204 mayalso encrypt request 220, digital signature 222, and/or public keycertificate 226 using a public cryptographic key associated withrepository system 110, e.g., prior to transmission across network 102 byclient device 202.

A programmatic interface established and maintained by repository system110, such as an application programming interface (API) 230, may receiverequest 220, applied digital signature 222, and a public key certificate226, and may perform operations that route request 220, applied digitalsignature 222, and a public key certificate 226 to a verification andconsent engine 232 executed by the one or more processors of repositorysystem 110. In some instances, all, or a selected portion, of request220, digital signature 222, and public key certificate 226 may beencrypted, and executed verification and consent engine 232 may performoperations (not illustrated in FIG. 2A) that decrypt the encryptedportions of request 220, digital signature 222, or public keycertificate 226 using a public cryptographic key associated withrepository system 110.

Executed verification and consent engine 232 may also perform operationsthat validate digital signature 222 using public cryptographic key 228,e.g., as obtained from public key certificate 226. If, for example,executed verification and consent engine 232 were unable to validatedigital signature 222, executed verification and consent engine 232 mayperform operations (not illustrated in FIG. 2A) that cause repositorysystem 110 to generate and transmit an error message characterizing thefailed validation of digital signature 222 across network 102 to clientdevice 202, and may discard request 220, digital signature 222, andpublic key certificate 226.

Alternatively, if executed verification and consent engine 232 were tovalidate successfully digital signature 222, executed verification andconsent engine 134 may perform operations that store request 220,digital signature 222, and public key certificate 226 within a portionone or more tangible, non-tangible memories, e.g., within a portion ofdata repository 236. Further, and based on the successful validationsignature 222, executed verification and consent engine 232 may providerequest 220, which includes customer identifier 218, element identifier214, and modification data 216, as an input to a management engine 238executed by the one or more processors of repository system 110, whichmay perform operations that establish a consistency between therequested modification, update, or addition to reference data store 112and one or more approval or consent criterion, and based on theestablished consistency, and approve or consent to the requestedmodification, update, or addition, and modify the elements of referencedata maintained within reference data store 112 in accordance withrequest 220.

In some instances, executed management engine 238 may perform operationsthat parse request 220 to: (i) obtain customer identifier 218, whichuniquely identifies user 201 within reference data store 112; (ii)obtain element identifier 214, which identifies the element of referencedata maintained within reference data store 112 and subject tomodification in accordance with request 220 (e.g., the customer'stelephone number); and (iii) obtain modification data 216, whichincludes the requested modification, update, or addition to thatidentified element of reference data (e.g., the updated phone number“5559876543”). Further, as illustrated in FIG. 2A, executed managementengine 238 may also obtain, from data repository 236, approval andconsent criteria data 240, which identifies and characterizes one ormore criterion with which executed management engine 238 approves of, orconsents to, the requested modification, update, or addition to theidentified element of reference data.

Executed management engine 238 may also determine the request 220corresponds to a requested update to the customer telephone numbermaintained within reference data store 112 (e.g., as specified byelement identifier 214), and that the requested update includes a linearstring of nine numbers corresponding to the updated phone number (e.g.,“5559876543” included within modification data 216). Further, approvaland consent criteria data 240 may include, but is not limited to, acorresponding approval and consent criterion that specifies an approvedformat or composition of updates to the customer phone number, e.g., thelinear string of nine numbers described herein. In some instances,executed management engine 238 may process modification data 216 andperform operations that establish a consistency between a compositionand format or the requested update to the customer phone number withinreference data store 112 (e.g., the updated customer telephone number“5559876543”) and the approved composition and format specified withinapproval and consent criteria data 240 (e.g., the linear string of ninenumbers). Based on the established consistency between the compositionand format or the requested update and the approved composition andformat, and based on the successful validation of digital signature 222(which establishes the approval or consent of executed mobile bankingapplication 204 or user 201 to the requested update), executedmanagement engine 238 may determine to approve, or consent to, therequested update to the customer phone number, and may performoperations that modify one or more elements of reference data associatedwith user 201 to reflect the requested update, e.g., as specified withinrequest 220.

For example, executed management engine 238 may access reference datastore 112, and identify one or more data records 242 that include, orreference, customer identifier 218 and as such, include elements ofreference data associated with customer 201. Executed management engine238 may also perform operations that parse elements of reference dataassociated with customer 201 (e.g., as included within data records242), and identify an element 244 of reference data associated withelement identifier 214, e.g., the currently maintained customertelephone number “5551234567.” Further, executed management engine 238may perform additional operations that modify the elements of referencedata within data records 242 to replace element 244 (e.g., the currentlymaintained customer telephone number “5551234567”) with all, or aselected portion, of modification data 216 (e.g., the updated customertelephone number “5559876543”). In some instances, the exemplaryoperations performed by executed management engine 238 to accessreference data store 112 and to identify or parse one or more of datarecords 242, may include one or more read operations on those portionsof one or more the tangible, non-transitory memories associated withreference data store 112, and the exemplary operations performed byexecuted management engine 238 to replace element 244 modification data216 may include one or more write operations on those portions of one ormore the tangible, non-transitory memories associated with referencedata store 112.

Further, executed management engine 238 may also generate proposal data246, which identifies and characterizes the requested, and approved andperformed modification to the reference data maintained within referencedata store 112. In some instances, and for a requested modification toan existing element of reference data maintained within reference datastore 112, proposal data 246 may include information associated with orrepresentative of the existing element of reference data (e.g., theactual, existing element of reference data, a cryptographic ornon-cryptographic representation of the existing element of referencedata, etc.), along with the updated or modified element of referencedata. In other instances, and for a requested addition to the existingelements of reference data maintained within reference data store 112,proposal data 246 may include the newly added element of reference data,along with information, e.g., a data flag, indicative of the requested,approved, and performed addition. Further, in some instances, theelements of proposal data 246 may also include additional, or alternate,elements of data that identify user 201 (e.g., the requesting customer),client device 202 or executed mobile banking application 204 (e.g., therequesting device or application), or repository system 110. Thedisclosed embodiments are, however, not limited to these exemplaryelements of proposal data 246, and in other instances, proposal data 246may include any additional or alternate data identifying orcharacterizing a request, approved, or implemented modification, update,or addition to the existing elements of reference data maintained withinreference data store 112.

In some instances, executed management engine 238 may package request220 (e.g., that includes customer identifier 218, element identifier214, and modification data 216), digital signature 222 (e.g., thatconfirms an approval of the requested update to the customer telephonenumber by user 201 or executed mobile banking application 204), andpublic key certificate 226 (e.g., that includes public cryptographic key228 associated with executed mobile banking application 204) intocorresponding portions of proposal data 246. Further, as illustrated inFIG. 2A, executed management engine 238 may package existing element 244of reference data (e.g., the customer telephone number (“5551234567”)maintained currently within reference data store 112) into acorresponding portion of proposal data 246, along with one or moreidentifiers 248 of repository system 110, such as, but not limited to, anetwork address of repository system 110 (e.g., an IP address, a MACaddress, etc.) or an application cryptogram associated with executedmanagement engine 238.

As illustrated in FIG. 2A, and using any of the exemplary processesdescribed herein, executed management engine 238 also generate and applya digital signature 250 to proposal data 246 using a privatecryptographic key associated with repository system 110, such as privatecryptographic key 127 of FIG. 1A. Executed management engine 238 mayalso perform operations that cause repository system 110 to broadcastproposal data 246, digital signature 250, and a public key certificateassociated with repository system 110 (e.g., public key certificate 129of FIG. 1A, which includes corresponding public cryptographic key 129A)across network 102 to one or more of notary systems 130, includingnotary system 132. Further, in some instances (not illustrated in FIG.2A), executed management engine 238 may also encrypt proposal data 246,digital signature 250, and/or public key certificate 129 using a publiccryptographic key associated with one or more of notary systems 130,e.g., prior to transmission across network 102 by repository system 110.

Referring to FIG. 2B, a programmatic interface established andmaintained by each of the one or more of notary systems 130, such as API133 of notary system 132, may receive proposal data 246, digitalsignature 250, public key certificate 129 (which include correspondingpublic cryptographic key 129A) from repository system 110, and may routeproposal data 246, digital signature 250, public key certificate 129 toexecuted verification and consent engine 134. As described herein,proposal data 246 may include, among other things, approved request 220,which corresponds to the request, approved by repository system 110, toupdate a customer phone number associated with user 201 and maintainedwithin reference data store 112. Further, approved request 220 mayinclude, among other things: customer identifier 218, which uniquelyidentifies user 201 within reference data store 112; element identifier214, which identifies the element of reference data maintained withinreference data store 112 and subject to modification in accordance withrequest 220 (e.g., the customer's existing telephone number); andmodification data 216, which includes the requested modification,update, or addition to that identified element of reference data (e.g.,the updated phone number “5559876543”).

Further, and as described herein, approved request 220 may also include,but is not limited to: digital signature 222, which may be applied torequest 220 by executed mobile banking application 204; public keycertificate 226 associated with mobile banking application 204(including corresponding public cryptographic key 228); existing dataelement 244, which specifies the existing customer phone numbermaintained within reference data store 112 prior to modification inaccordance with modification data 216); and identifier 248 associatedwith repository system 110, such as an IP or MAC address. The disclosedembodiments are, however, not limited to these exemplary components ofproposal data 246, and in other instances, proposal data 246 may includeany additional or alternate elements of data that identify andcharacterize a proposed modification of, update to, or addition to theelements of reference data maintained within reference data store 112,that establish an approval or consent of repository system to theproposed modification, or that establish an approval or a consent ofuser 201 or executed mobile banking application 204 to the requestedmodification.

Executed verification and consent engine 134 may receive proposal data246, digital signature 250, and public key certificate 129, and in someinstances, may perform operations (not illustrated in FIG. 2B) thatdecrypt the encrypted portions of request 220, digital signature 222, orpublic key certificate 226 using a private cryptographic key associatedwith notary systems 130, such as private cryptographic key 137 of notarysystem 132. Further, executed verification and consent engine 134 mayalso perform operations that validate digital signature 250 using publiccryptographic key 129A (e.g., as obtained from public key certificate129), and based on a successful validation of digital signature 250,executed verification and consent engine 134 may authenticate anidentity of repository system 110, and further, establish an integrityof the data maintained within proposal data 246. In some instances, asuccessful validation of digital signature 250 by executed verificationand consent engine 134 may also be indicative of an approval, or aconsent, of repository system 110 (e.g., that operates as the computingsystem of record for the elements of reference data maintained withinreference data store 112) to the requested update to the customer phonenumber maintained within reference data store 112 and further, may alsobe indicative of a performance of that requested update to the elementsof reference data maintained within reference data store 112.

Additionally or alternatively, executed verification and consent engine134 may also parse proposal data 246 to obtain request 220, applieddigital signature 222, and public key certificate 226 of executed mobilebanking application 204 or client device 202, and may perform additionaloperations that validate digital signature 250 using publiccryptographic key 129A, e.g., as obtained from public key certificate129. In some instances, and through a successful validation of applieddigital signature 250, executed verification and consent engine 134 maynot only authenticate an identity of executed mobile banking application204 (and as such, or client device 202) and establish an integrity ofrequest 220, but also confirm an approval of, and a consent to, thenow-performed update to reference data store 112 by executed mobilebanking application 204 and client device 202.

If, for example, executed verification and consent engine 134 wereunable to validate digital signature 250 or were unable to validatedigital signature 222, notary system 132 (and additional, or alternate,ones of notary systems 130) may decline to notarize the update to theelements of reference data maintained at repository system 110 using anyof the exemplary, consensus-based notarization processes describedherein. In response to the unsuccessful validation of digital signature250 (and/or digital signature 222), executed verification and consentengine 134 may perform operations (not illustrated in FIG. 2B) thatcause notary system 132 (and additional or alternate ones of notarysystems 130) to generate and transmit an error message characterizingthe failed validation across network 102 to repository system 110, andmay discard proposal data 246, digital signature 250, and public keycertificate 129.

In other examples, and based on the successful validation of digitalsignature 250 (and additionally, or alternatively, of digital signature222), executed verification and consent engine 134 may performoperations that store proposal data 246 within a portion one or moretangible, non-tangible memories or notary system 132, e.g., within aportion of notary data store 136. Further, executed verification andconsent engine 134 may provide proposal data 246 as an input to anotarization management engine 252 of notary system 132 (and ofadditional, or alternate, ones of notary systems 130). When executed bythe one or more processors of notary system 132 (and each additional, oralternate, one of notary systems 130), notarization management engine252 may process proposal data 246, extract request 220, existing dataelement 244, and/or system identifier 248 from proposal data 246, andfurther, may perform operations that trigger an execution of the one ormore elements of code recorded within smart contract elements 150 ofnotarized distributed ledger 142, such as distributed notarizationmodule 152, in conjunction with corresponding recorded elements ofsupporting data, such as notarization criteria 154 recorded within smartcontract elements 150.

As described herein, the recorded elements of code or softwareinstructions and supporting data, including distributed notarizationmodule 152 and notarization criteria 154, may collectively establish adistributed notarization contract within notarized distributed ledger142. In some instances, the distributed notarization contract mayestablish one or more conditions that, when application to proposal data246 by one or more of notary systems 130 (including notary system 132)through any of the exemplary consensus-based processes described herein,indicate whether the one or more of notary system 130 may approveproposed modification to the elements of reference data maintainedwithin reference data store 112 and record the approved modificationwithin an additional element of notarized distributed ledger 142 (e.g.,to “notarize” the requested modification), or alternatively, to rejectthe proposed modification and notify the requesting computing system ordevice within environment 100 that proposed the modification, e.g.,repository system 110. Through certain of these exemplary,consensus-based processes, the implementation of the distributednotarization contract may prevent or minimize any instances ofimpermissible “double updates,” i.e., simultaneous requests for distinctmodifications, updates, or addition to a single element of the referencedata maintained within reference data store 112, and may resolve orprioritize requests to modify, update, or add to the elements ofreference data received sequentially from various computing systems ordevices operating within environment 100.

Referring back to FIG. 2B, and upon execution by the one or moreprocessors of notary system 132 (and by each additional or alternate oneof notary systems 130), distributed notarization module 152 may receiveproposal data 246. In some instances, executed distributed notarizationmodule 152 may parse proposal data 246, and may perform operations thatextract, from proposal data 246, one or more of: (i) customer identifier218, which identifies user 201 associated with the requested updated tothe customer phone number; (ii) element identifier 214 or existingelement identifier 244, which identify the element of reference datamaintained in reference data store 112 and subject to modification,update, or augmentation, e.g., the customer phone number; (iii)modification data 216, which identifies the requested modification tothe customer phone number; or (iv) system identifier 248 of repositorysystem 110, e.g., the system of record that maintains reference datastore 112, approved the requested modification, and generated proposaldata 246.

Executed distributed notarization module 152 may also accessnotarization criteria 154 (e.g., as maintained within smart contractelements 150 of notarized distributed ledger 142), and based on customeridentifier 218, extracted element identifier 214 or existing elementidentifier 244, extracted modification data 216, and/or extracted systemidentifier 248, executed distributed notarization module 152 mayidentify and obtain one or more discrete notification criteriaassociated with proposal data 246. The discrete notification criteriamay include, but are not limited to, a customer-specific notificationcriterion, a data-specific notification criterion, amodification-specific notification criterion, or a system-specificnotification criterion. Further, each of the discrete notification dataobtained from notification criteria may include a correspondingcustomer-, data-, modification-, or system-specific condition that, whenapplied to portions of proposal data 246, enable notary system 132 (andadditional, or alternate, ones of notary systems 130) to perform any ofthe consensus-based operations described herein to approve the proposedmodification associated with proposal data 246 and generate anadditional element of notarized distributed ledger that includes datarepresentative of the approved modification (e.g., to “notarize” theproposed modification to reference data store 112), or alternatively, toperform operations that reject the proposed modification, to referencedata store 112 and that notify a computing system or device associatedwith now-rejected proposal data 246, e.g., repository system 110.

For example, notarization criteria 154 may include a system-basednotarization criterion 254 that instructs each of notary systems 130 tonotarize any modification, update, or additional to reference data store112 approved by the corresponding system of record (e.g., repositorysystem 110) using any of the exemplary, consensus-based processesdescribed herein, and that includes one or more unique identifiers ofthat system of records, such as an IP address or a MAC address ofrepository system 110. In some instances, executed distributednotarization module 152 may determine that proposal data 246 referencesa request to notarize an update to a customer phone number maintainedwithin reference data store 112, and that repository system 110, actingas the system of record, approved the update to the customer phonenumber. Further, executed distributed notarization module 152 may obtainthe IP or MAC address of repository system 110 from system identifier248, and may perform operations identify system-based notarizationcriterion 254 within notarization criteria 154 based on the IP or MACaddress of repository system 110, and that obtain system-basednotarization criterion 254 from notification criteria.

Based on an application of system-based notarization criterion 254 toproposal data 246, executed distributed notarization module 152 maydetermine to approve the modification to the customer phone numberpreviously approved by repository system 110. Executed distributednotarization module 152 may generate confirmation data 256 indicative ofthe approved modification to the customer phone number associated withproposal data 246, and may perform operations that route confirmationdata 256 back to executed notarization management engine 252. In someinstances, and based on the approval of the modification associated withproposal data 246 (e.g., by executed distributed notarization module152), executed notarization management engine 252 may provide all, or aselected portion, of now-approved proposal data 246 as an input toexecuted block generation engine 138, which may perform any of theexemplary, consensus-based processes described herein to generate anadditional element 260 of notarized distributed ledger 142 that includes(e.g., records) data representative of the notarized update to thecustomer phone number maintained within reference data store 112 (e.g.,as associated with proposal data 246), and to generate a latest, longestversion of notarized distributed ledger 142 that includes additionalelement 260.

As illustrated in FIG. 2B, additional element 260 may include, amongother things, notarization data 262 that identifies, and characterizes,the notarized update to the customer phone number of user 201 maintainedwithin reference data store 112. For example, notarization data 262 mayinclude the updated phone number of user 201 (e.g., “5559876543,” asspecified within modification data 216), along with one or more ofcustomer identifier 218, which uniquely identifies user 201 within thedata records of reference data store 112, element identifier 214, whichuniquely identifies the customer phone number within the data records ofreference data store 112, and system identifier 248 that uniquelyidentifies repository system 112. In some examples, notarization data262 may include additional, or alternate, data representative of thenotarized update, which as, but not limited to, a cryptographic ornon-cryptographic hash generated by executed block generation engine 138through an application of a corresponding cryptographic ornon-cryptographic hash algorithm or all, or a selected subset, of theupdated phone number of user 201 (e.g., all, or a selected subset, of“5559876543”). Further, and in other examples, notarization data 262 mayinclude the notarized update to the customer phone number of user 201(e.g., “5559876543,” as specified within modification data 216) and thecryptographic or non-cryptographic hash representative of that notarizedupdate, either alone or in conjunction with additional datacharacterizing the notarized update or the corresponding element ofreference data within reference data store 112, such as metadata thatcharacterizes the updated element of reference data (e.g., the customerphone number) or a modification type associated with the notarizedupdate e.g., an update to an existing element of reference data).

In some instances, additional element 260 may also include temporal data264, which specifies a time or date associated the approval of thenotarized update to the customer phone number (e.g., by executeddistributed notarization module 152) and/or the generation of additionalelement 260 (e.g., by executed block generation engine 138). Asdescribed herein, an inclusion of temporal data 264 within additionalelement 260 may facilitate a determination, by notary system 132 (and byother ones of notary systems 130) that the notarized update to thecustomer phone number maintained within reference data store 112occurred subsequent to a prior replication of the one or more elementsof reference data maintained within reference data store 112 to one ormore additional computing systems operating within environment 100, suchas, but not limited to, local computing system 172 (e.g., based oncorresponding temporal data maintained within a prior element ofnotarized distributed ledger 142, such as element 140).

Executed block generation engine 138 (and the block generation engineexecuted by additional ones of notary systems 130) may also perform anyof the exemplary processes described herein to generate and apply adigital signature 266 to all, or a selected portion, of notarizationdata 262. Further, executed block generation engine 138 may generate ahash value 268 based on an application of one or more appropriate hashalgorithms to notarization data 262 and digital signature 144 (and insome instances, to other elements of notarized distributed ledger 142,such as a hash value representative included within a previouslyrecorded element of notarized distributed ledger 142, such as hash value146 of element 140). Executed block generation engine 138 may packagedigital signature 266 and hash value 268 into corresponding portions ofadditional element 260, e.g., in conjunction with the portion ofnotarization data 262.

Notary system 132 may perform further operations, established through adistributed consensus among additional ones of notary systems 130, thatgenerate and assign an index 270 to additional element 260, thatincorporate index 270 within a corresponding portion of additionalelement 260, and that append additional element 260 to a prior versionof notarized distributed ledger (e.g., notarized distributed ledger 142)to generate a latest, longest version of notarized distributed ledger142, e.g., notarized distributed ledger 272. As described herein, index270 may correspond to a positional identifier (e.g., a “block number”)that specifies a sequential position of element 260 relative to theexisting, prior elements of notarized distributed ledger 272. Further,in some instances, notarized distributed ledger 272 may reflect reflectsthe notarized modification to the customer phone number of user 201maintained within reference data store 112 by repository system 110, andas such, an updated composition, and an “updated” snapshot, of referencedata store 112.

These additional operations, established through the distributedconsensus among notary systems 130, may include, but are not limited to,a calculation of an appropriate proof-of-work or proof-of-stake by adistributed consensus engine 149 executed at notary system 132 prior toa calculation of corresponding proofs-of-work or proofs-of-stake byothers of notary systems 130. In some instances, notary system 132 maybroadcast evidence of the calculated proof-of-work or proof-of-stake toone or more additional ones of notary systems 130 across network 102(not illustrated in FIG. 2B).

Notary system 132 may also broadcast notarized distributed ledger 272,which represents the latest, longest version of the immutable,cryptographically secure, notarized distributed ledger, across network102 to the additional ones of notary systems 130 operating withinenvironment 100. Further, although not illustrated in FIG. 2B, notarysystem 132 may also perform operations that generate and transmit anotification indicative of the successful, approved notarization of theupdate to reference data store 112 associated with proposal data 246(e.g., the update to the phone number of user 201 within reference datastore 112, as previously approved by repository system 110 using any ofthe exemplary processes described herein) across network 102 torepository system 110.

In some instances, one or more of the notarized distributed ledgersdescribed herein, such as notarized distributed ledger 272, mayestablish an immutable, time-evolving, and auditable record of not onlythe elements of reference data (e.g., as maintained within referencedata store 112) that are replicated to other computing systems anddevices operating within environment 100, but also subsequent, notarizedmodifications, updated, or additions to each of these elements ofreference data. Further, the immutable, time-evolving, and auditablerecord established by notarized distributed ledger 272 may furtherestablish a queue of notarized modifications, updated, or additionsawaiting provisioning to the one or more additional computing systemsoperating within environment 100, such as, but not limited to, localcomputing system 172 for replication and local storage, e.g., withinreplicated data store 184.

For example, and referring to FIG. 2C, a provisioning engine executed bythe one or more processors of notary system 132 (and additionally, oralternatively, by other ones of notary systems 130), such asprovisioning engine 156, may perform operations that access notarizeddistributed ledger 272 and further, that identify and access additionalelement 260 associated with the newly notarized update to the phonenumber maintained within reference data store 112 at repository system110. By way of example, notary system 132 may maintain notarizeddistributed ledger 272 within one or more tangible, non-transitorymemories, such as notary data store 136, and executed provisioningengine 156 may access notary data store 136, obtain notarizeddistributed ledger 272 from accessed notary data store 136, and identifyadditional element 260 (e.g., the temporally most recent element ofnotarized distributed ledger 272) based on temporal data 264 andadditionally, or alternatively, based on index 270.

Executed provisioning engine 156 may obtain, from additional element260, notarization data 262, which includes modification data 216specifying the modified phone number of user 201 (and additionally, oralternatively, the cryptographic or non-cryptographic hash valuerepresentative of the updated phone number), customer identifier 218,element identifier 214, and system identifier 248. Further, executedprovisioning engine 156 may also obtain temporal data 264, whichspecifies the time or date associated the approval of the notarizedupdate to the customer phone number, from additional element 260. Insome instances, executed provisioning engine 156 may perform operationsthat generate updated replication data 274, and that packagemodification data 216 specifying the updated phone number (andadditionally, or alternatively, the cryptographic or non-cryptographichash value representative of the updated phone number), temporal data264, and one or more of customer identifier 218, and element identifier214 into corresponding portions of updated replication data 274.

Further, executed provisioning engine 156 may also perform any of theexemplary processes described herein to generate and apply a digitalsignature 276 to updated replication data 274 using privatecryptographic key 137 associated with notary system 132 and other ofnotary systems 130. Executed provisioning engine 156 may also performoperations that cause notary system 132 to broadcast updated replicationdata 274, applied digital signature 276, and public key certificate 164associated with notary system 132 (which includes a corresponding publiccryptographic key 166) across network 102 to one or more additionalcomputing systems within environment 100, such as local repositorysystem 172 that executed SaaS application 174. In some instances, andprior to transmission across network 102 by client device 202, executedprovisioning engine 156 may also encrypt updated replication data 274,applied digital signature 276, and/or public key certificate 164 using apublic cryptographic key associated with the one or more additionalcomputing systems, such as public cryptographic key 160 associated withSaaS application 174 executed at local repository system 172.

In other examples, and upon completion of the exemplary provisioningprocesses described herein, executed provisioning engine 156 maygenerate one or more elements of data, such as provisioning flag 278,indicative a successful provisioning of updated replication data 274 andas such, the updated phone number (e.g., as specified by notificationdata 262 and temporal data 264 within updated replication data 274) tolocal repository system 172. As illustrated in FIG. 2C, executedprovisioning engine 156 may provide provisioning flag 278 as an input toexecuted block generation engine 138, along with all, or a selectedportion, of updated replication data 274 and additional temporal data280 that identifies a time or date at which notary system 132 (andadditional, or alternate, ones of notary systems 130) broadcast updatedreplication data 274 to local repository system 172.

Executed block generation engine 138 may, for example, perform any ofthe exemplary consensus-based processes described herein (e.g., based ona distributed consensus between notary system 132 and one or more othersof notary systems 130) to generate a further element 282 of notarizeddistributed ledger 272 that includes provisioning flag 278, the portionsof updated replication data 274, and temporal data 280, and to appendfurther element 282 to notarized distributed ledger 272 and generate alatest, longest version of notarized distributed ledger 272 thatincludes further element 282, e.g., notarized distributed ledger 284. Insome instances, further element 282 may also include information, suchas index 285, that identifies or references further element 282associated with the notarized update to the phone number withinreference data store 112 and as such, further element 282 may confirmthat notary system 132 (and additionally, or alternatively, others ofnotary systems 130) provisioned the updated phone number to localcomputing system 172 for replication and storage, e.g., withinreplicated data store 184.

In some instances, one or more of the exemplary notarized distributedledgers described herein, such as notarized distributed ledger 284, mayinclude further elements that identify and characterize additional, oralternate, modifications, updates, or additions to reference data store112. For example, these elements may be notarized, and recorded ontonotarized distributed ledger 284, prior to element 260 (e.g.,characterizing the update to the customer phone number of user 201), butsubsequent to element 140, which identifies and characterizes thereplication of the elements of reference data within reference datastore 112 to the one or more computing systems or devices withinenvironment 100, such as, but not limited to, local computing system172.

Although not illustrated in FIG. 2C, executed provisioning engine 156may access, in a temporal sequence defined by corresponding positionalidentifiers and corresponding temporal data, each of these furtherelements of notarized distributed ledger 284, and may perform any of theexemplary processes described herein to broadcast updated replicationdata identifying and characterizing corresponding ones of the notarizedmodifications to reference data store 112, to local repository system172, and/or to one or more additional computing systems across network102. Executed provisioning engine 156 may also perform any of theexemplary processes described herein to generate additional data, suchas a provisioning flag, indicative of a successful provisioning of theupdated replication data associated with each of the correspondingmodifications, updates, or additions to reference data store 112, and torecord these provisioning flags within one or more elements of a latest,longest version of notarized distributed ledger 284.

In other instances, not illustrated in FIG. 2C, notary system 132 mayperform operations that establish, within the one or more tangible,non-transitory memories, a replication queue that includes discreteelements of queued notarization data and corresponding temporal dataidentifying and characterizing one or more of the modifications toreference data store 112 notarized subsequent to the replication of theelements of reference data within reference data store 112 to the one ormore computing systems or devices within environment 100, such as, butnot limited to, local repository system 172. For example, the discreteelements of notarization data may be prioritized within the replicationqueue based on, among other things, one or more temporal criterion(e.g., prioritizing discrete elements of notarization data in accordingwith corresponding a temporal pendency within replication queue), one ormore data-specific criterion (e.g., prioritizing discrete elements ofnotarization data associated with certain types of reference data, suchas customer profile data, etc.), or one or more customer-specificcriterion (e.g., prioritizing discrete elements of notarization dataassociated with commercial customers, etc.).

Executed provisioning engine 156 may, for example, access sequentiallyeach of the queued elements of notarization data maintained within thereplication queue, and perform any of the exemplary processes describedherein to broadcast updated replication data identifying andcharacterizing corresponding ones of the modifications to reference datastore 112 across network 102 to the one or more additional computingsystems, including local repository system 172, in accordance with thesequential access (not illustrated in FIG. 2B). Executed provisioningengine 156 may also perform any of the exemplary processes describedherein to generate additional data, such as a provisioning flag,indicative of a successful provisioning of the updated replication dataassociated with each of the corresponding modifications to referencedata store 112, and to store these provisioning flags within thereplication queue in conjunction, or association, with correspondingones of the prioritized elements of notarization data. Executedprovisioning engine 156 may also perform any of the exemplary processesdescribed herein to record these provisioning flags within one or moreelements of a latest, longest version of notarized distributed ledger284.

Referring to FIG. 2D, a programmatic interface established andmaintained by local repository system 172, such as API 176 associatedwith executed SaaS application 174, may receive updated replication data274, digital signature 276, and public key certificate 164 (whichincludes corresponding public cryptographic key 166), and may routeupdated replication data 274, digital signature 276, and public keycertificate 164 to verification and consent module 178 of executed SaaSapplication 174. As described herein, all, or a selected portion, ofreplication data 274, digital signature 276, and public key certificate164 may be encrypted (e.g., using public cryptographic key 160associated with SaaS application 174), and executed verification andconsent module 178 may perform operations that decrypt the encryptedportions of updated replication data 274, digital signature 276, andpublic key certificate 164 using a private cryptographic key associatedwith SaaS application 174, such as private cryptographic key 180.

Executed verification and consent module 178 may also perform operationsthat validate digital signature 276 using public cryptographic key 166,e.g., as obtained from public key certificate 164. If, for example,executed verification and consent module 178 were unable to validatedigital signature 276, executed verification and consent module 178 maygenerate and transmit an error message characterizing the failedvalidation of digital signature 276 across network 102 to notary system132, and may discard updated replication data 274, digital signature276, and public key certificate 164.

Alternatively, if executed verification and consent module 178 were tovalidate successfully digital signature 276, executed verification andconsent module 178 may provide decrypted replication data 274 as aninput to local replication module 182 of executed SaaS application 174.In some instances, executed local replication module 182 may perform anyof the exemplary processes described herein to access replicated datastore 184, identify the one or more elements of replicated referencedata 186 within replicated data store 184 that are referenced by updatedreplication data 274, and modify each of the one or more identifiedelements of replicated reference data 186 in accordance with updatedreplication data 274.

For example, executed local replication module 182 may performoperations that parse updated replication data 274 to: (i) obtaincustomer identifier 218, which uniquely identifies user 201 withinreference data store 112; (ii) obtain element identifier 214, whichidentifies the element of reference data maintained within referencedata store 112 and subject to modification in accordance with updatedreplication data 274 (e.g., the customer's telephone number); and (iii)obtain modification data 216, which includes the requested modification,update, or addition to that identified element of reference data (e.g.,the updated phone number “5559876543”). Further, executed localreplication module 182 may access replicated data store 184, andidentify one or more data records 286 that include, or reference,customer identifier 218 and as such, include elements of reference dataassociated with customer 201. Executed local replication module 182 mayalso perform operations that parse elements of reference data associatedwith customer 201 (e.g., as included within data records 286), andidentify an element 288 of reference data associated with elementidentifier 214, e.g., the locally replicated customer telephone number“5551234567.”

In some instances, executed local replication module 182 may performadditional operations that modify the elements of reference data withindata records 286 to replace element 288 (e.g., the locally replicatedcustomer telephone number “5551234567”) with all, or a selected portion,of modification data 216 (e.g., the updated customer telephone number“5559876543”). In some instances, the exemplary operations performed byexecuted local replication module 182 to access replicated data store184, and to identify or parse one or more of data records 286, mayinclude one or more read operations on those portions of one or more thetangible, non-transitory memories associated with replicated data store184, and the exemplary operations performed by executed localreplication module 182 to replace element 288 with the portion ofmodification data 216 may include one or more write operations on thoseportions of one or more the tangible, non-transitory memories associatedwith replicated data store 184.

Executed local replication module 182 may also perform operations thatprovide modification data 216, which includes the updated phone numberof user 201 (e.g., as updated within data records 286 of replicated datastore 184), and temporal data 290, which specifies at time at date atwhich local replication module 182 updated data records 286 to includethe updated phone number, as inputs to local block generation module 192of executed SaaS application 174. In some instances, executed localblock generation module 192 may perform any of the exemplary processesdescribed herein to generate an additional element 292 of localdistributed ledger 190 that includes modification data 216 (e.g., theupdated customer telephone number “5559876543”) and/or informationrepresentative of the updated customer telephone number (e.g., acryptographic or non-cryptographic hash value) and temporal data 290. Insome examples, element 292 may be representative of a modified state ofthe replicated reference data 186 that includes the updated phone numberof user 201 maintained in reference data store 112 by repository system110. Further, executed local block generation module 192 may alsoperform any of the exemplary processes described herein to appendadditional element 292 to local distributed ledger 190, and to generatea latest, longest version of the immutable, cryptographically secure,local distributed ledger that includes additional element 292, e.g.,local distributed ledger 294.

In some instances, as described herein, user 201 may access, viaexecuted mobile banking application 204 at client device 202, one ormore elements of the reference data maintained at repository system 110within reference data store 112. User 201 may, for instance, provideinput to client device 202 requesting a modification to the one or moreelements of the reference data, and client device 202 may perform any ofthe exemplary processes described herein to generate a digitally signedrequest (e.g., request 220 of FIGS. 2A-2B) that reflects themodification, and to transmit the digitally signed request acrossnetwork 102 to repository system 110 (e.g., the system of record for theelements of reference data) via a secure, programmatic channel ofcommunications.

In other instances, client device 202 may execute application programsthat facilitate an interaction between user 201 and one or more elementsof reference data locally replicated by one or more additional oralternate computing systems within environment 100, such as replicatedreference data 186 maintained within replicated data store 184 of localrepository system 172. By way of example, local repository system 172may correspond to a customer-relationship management (CRM) systemexecuting one or more application programs, such as SaaS application174. In some instances, when executed by the one or more processors oflocal repository system 172, SaaS application 174 may perform operationsthat receive and respond to customer-specific inquiries received fromcorresponding computing systems or devices (e.g., client device 202operable by user 201) based on elements of replicated reference data186, which establish a “local replica” of the elements of reference datamaintained within reference data store 112, and which may be replicatedfrom repository system 110 using any of the exemplary notarizationprocesses described herein. For example, the local repository system 172may maintain, within replicated data store 184, elements of replicatedreference data 186 that collectively a “do not call” registry forcustomers of the financial institution, and executed SaaS application174 may perform operations that receive and processes requests orinquiries received from the customers of the financial institution, andfrom representatives of the financial institution, related to the “donot call” registry.

Further, in some instances, the elements of replicated reference data186 may include application data characterizing one or more applicationsfor financial products or services fully or partially completed bycorresponding prospective customers of the financial institution, e.g.,as identified through one or more of the browser-specific PKIfingerprints described herein, one or more split portions of acustomer-specific, public cryptographic key described herein, etc.Executed SaaS application 174 may perform operations that, based onrequests received from corresponding customer computing devices orsystems (e.g., client device 202) provision corresponding elements ofpartially completed application data to the customer computing devicesor systems, and that process fully completed applications for thefinancial services or products on behalf of the financial institution.The disclosed embodiments are, however, not limited to these examples oflocally replicated reference data, or to these exemplary CRM functionsperformed by executed SaaS application 174, and in other instances,replicated data store 184 may include any additional, or alternate,elements of reference data supporting any a performance of anyadditional, or alternate, CRM functionality by executed SaaS application174.

For example, local repository system 172 may receive, across network 102through a secure, programmatic channel of communications, one or morerequests from the customer computing systems or devices to modify theelements of replicated reference data 186 maintained by local repositorysystem 172 within replicated data store 184. In some instances,described below in reference to FIGS. 3A, 3B, 4A, and 4B, executed SaaSapplication 174 may perform operations that broadcast each of therequested modifications, and an applied digital signature, acrossnetwork 102 to one or more of notary systems 130, including notarysystem 132, which may perform any of the exemplary, consensus-basednotarization processes described herein to notarize each of therequested modifications, within an element of a notarized distributedledger, to generate one or more additional elements of the notarizeddistributed ledger that includes data representative of the notarizedmodifications. One or more of notary systems 130, such as notary system132, may also perform operations that transmit information confirmingeach of the notarized modifications across network 102 to repositorysystem 110 (e.g., the system of record that maintains reference datastore 112) and further, to local repository system 172 that maintainsreplicated data store 184.

As described herein, executed SaaS application 174 at local repositorysystem 172 may receive the information confirming each of notarizedmodifications, and may modify the locally replicated elements ofreference data (e.g., within replicated data store 184 of localrepository system 172) in accordance with corresponding ones of thenotarized modifications. Further, in some examples, one or moreapplication programs, engines, or modules executed at repository system110 may receive the information confirming each of notarizedmodifications, and may perform operations that modify accordingly theelements of reference data maintained within reference data store 112.Certain of these exemplary processes may, for example, may prevent orminimize any instances of impermissible “double updates,” i.e.,simultaneous requests for distinct modifications, updates, or additionto a single element of the reference data maintained within referencedata store 112, and may resolve or prioritize requests to modify,update, or add to the elements of reference data received sequentiallyfrom various computing systems or devices operating within environment100.

Referring to FIG. 3A, user 201 may elect to add a new customer phonenumber to the “do-not-call” registry established by the elements ofreference data maintained within replicated data store 184 of localrepository system 172. In some instances, to facilitate the addition ofthe customer phone number to the do-not-call registry maintained withinreplicated data store 184, user 201 may provide input to client device202 (e.g., via the corresponding input unit) that requests an executionof one or more application programs associated with local repositorysystem 172 or executed SaaS application 174, such as mobile SaaSapplication 302 (or alternatively, that requests an execution of acorresponding web browser). Upon execution by the one or more processorsof client device 202, executed mobile SaaS application 302 (or theexecuted web browser) may perform operations that initiate one or moreof the exemplary authentication processes described herein.

Based on a successful outcome of the authentication process, executedmobile SaaS application 302 may perform operations that cause clientdevice 202 to establish a secure, programmatic channel of communicationswith local repository system 172, and further, may generate and present,within a digital interface 304, additional interface elements thatenable user 201 to view, and interact with, and request a modificationor addition to customer-specific portions of the do-not-call registrymaintained locally within replicated data store 184. In some instances,and responsive to the successful outcome of the authentication process,executed mobile SaaS application 302 may request and receive, from localrepository system 172, one or more elements of replicated reference data186 associated with user 201 and maintained within replicated data store184 (e.g., one or more existing phone numbers of user 201 within thedo-not-call registry). Executed mobile SaaS application 302 may alsoperform operations that present all or a selected portion of replicatedreference data 186 within digital interface 304, along with additionalinterface elements that prompt user 201 to provide additional input toclient device 202 that updates, modifies, or adds to those portions ofthe do-not-call registry associated with user 201.

For example, digital interface 304 may include interface elements 306A,which identify an existing telephone number of user 201 within thedo-not-call registry maintained by executed SaaS application 174 (e.g.,“5551234567”) and selectable interface element 306B, which uponselection by user 201, indicates an intention of user 201 to delete theexisting telephone number from the do-not-call registry. Further,digital interface 304 may also include a fillable text box 306C andadditional interface elements 306D, which prompt user 201 to enter anupdated phone number within fillable text box 306C, e.g., for additiononto the do-not-call registry maintained by executed SaaS application174. Digital interface 206 may also include selectable interface element306E, which upon selection by user 201, confirms a consent of user 201to the update to or modification of the do-not-call registry, andrequests a submission of the update or modification to local repositorysystem 172. The disclosed embodiments are, however, not limited to theseexemplary interface elements, and in other instances, executed mobileSaaS application 302 may present any additional, or alternate, number ortype of interface elements within digital interface 304 that would beappropriate to the received elements of replicated reference data.

As illustrated in FIG. 3A, user 201 may provide, via input unit 203B ofclient device 202, input 308 to digital interface 304 that specifies theupdated phone number of user 201 (e.g., an input of “5559876543” withinfillable text box 304C), that confirms the consent of user 201 to theaddition of the updated phone number to the do-not-call list, andrequests the submission of the updated phone number to local repositorysystem 172 (e.g., responsive to a selection of selectable interfaceelement 208E). In some instances, and in addition to, or as an alternateto, processes that confirm the consent of user 201 based on theselection of selectable interface element 208D, executed mobile SaaSapplication 302 may present additional interface elements within digitalinterface 206 (not illustrated in FIG. 3A) that prompt user 201 toconsent affirmatively to the update or modification to the phone number,e.g., based on a re-entry of a password of user 201 and/or based on asuccessful completion of one or more in-band or out-of-band challengeprocesses.

Input device 203 may receive input 308, and may route correspondingelements of input data 310, which includes all or a selected portion ofinput 308, to executed mobile SaaS application 302. For example, inputdata 310 may include, but is not limited to, data that identifies theelements of reference data subject to modification, update, oraugmentation by user 201, such as registry identifier 312 associatedwith the do-not-call registry within replicated data store 184 andreference data store 112, along with modification data 314 thatspecifies the requested addition to the do-not-call registry (e.g., theupdated phone number “5559876543”)

In some instances, executed mobile SaaS application 302 may receiveinput data 310, which includes registry identifier 312 and modificationdata 314, and may load, from the one or more tangible, non-transitorymemories, at least one of the authentication credentials associated withuser 201, such as customer identifier 316. Executed mobile SaaSapplication 302 may also perform operations that generate a request 318to add the updated phone number (e.g., “5559876543) to the do-not-callregistry within replicated data store 184, and that package customeridentifier 316, registry identifier 312, and modification data 314 intocorresponding portions of request 318. In some instances, notillustrated in FIG. 3A, executed mobile SaaS application 302 may alsoperform operations that package, within corresponding portions ofrequest 318, one or more identifiers of client device 202 (e.g., anetwork address, such as an IP or MAC address) and/or of executed mobileSaaS application 302 (e.g., an application cryptogram, etc.).

Further, executed mobile SaaS application 302 may also perform any ofthe exemplary processes described herein to generate and apply a digitalsignature 320 to request 318, which includes customer identifier 316,registry identifier 312, and modification data 314, using a privatecryptographic key 322 associated with executed mobile SaaS application302 or client device 202. As illustrated in FIG. 3A, executed mobileSaaS application 302 may perform operations that cause client device 202to transmit request 318, applied digital signature 320, and a public keycertificate 324 associated with executed mobile SaaS application 302 orclient device 202 (which includes a corresponding public cryptographickey 326) across network 102 to local repository system 172. Further, insome instances (not illustrated in FIG. 3A), executed mobile SaaSapplication 302 may also encrypt request 318, digital signature 320,and/or public key certificate 324 using a public cryptographic keyassociated with local repository system 172, e.g., prior to transmissionacross network 102 by client device 202.

A programmatic interface established and maintained by local repositorysystem 172, such as API 176 associated with executed SaaS application174, may receive request 318, applied digital signature 320, and apublic key certificate 324, and may perform operations that routerequest 318, applied digital signature 320, and a public key certificate324 to verification and consent module 178 of executed SaaS application174. In some instances, all, or a selected portion, of request 318,applied digital signature 320, and a public key certificate 324 may beencrypted (e.g., using the public cryptographic key associated withlocal repository system 172), and verification and consent module 178may decrypt the encrypted portions of request 318, applied digitalsignature 320, and a public key certificate 324 using a privatecryptographic key associated with local repository system 172 (notillustrated in FIG. 3A).

Verification and consent module 178 may also perform operations thatvalidate digital signature 320 using public cryptographic key 326, e.g.,as obtained from public key certificate 324. If, for example,verification and consent module 178 were unable to validate digitalsignature 320, verification and consent module 178 may performadditional operations (not illustrated in FIG. 3A) that cause localrepository system 172 to generate and transmit an error messagecharacterizing the failed validation of digital signature 320 acrossnetwork 102 to client device 202, and may discard request 318, applieddigital signature 320, and a public key certificate 324.

Alternatively, if verification and consent module 178 were to validatesuccessfully digital signature 320, verification and consent module 178may not only authenticate the identity of executed mobile SaaSapplication 302 (or client device 202) and establish the integrity ofthe data maintained within request 318, but also confirm a consent ofexecuted mobile SaaS application 302 to the requested addition of theupdated phone number to the do-not-call registry maintained withinreplicated data store 184 and within reference data store 112. Based onthe successful validation of digital signature 320, verification andconsent module 178 may provide request 318 (which includes customeridentifier 316, registry identifier 312, and modification data 314),applied digital signature 320, and a public key certificate 324 asinputs to local replication module 182 of executed SaaS application 174

As illustrated in FIG. 3A, local replication module 182 may performoperations that parse request 318 to: (i) obtain customer identifier 316that uniquely identifies user 201 within replicated data store 184 andreference data store 112; (ii) obtain registry identifier 312 associatedwith the do-not-call registry within replicated data store 184 andreference data store 112; and (iii) obtain with modification data 314that specifies the requested addition to the do-not-call registry, e.g.,the updated phone number “5559876543.” Further, local replication module182 may also perform operations that access replicated data store 184,and obtain temporal data 124 associated with the one or more elements ofreplicated reference data 186. As described herein, temporal data 124may specify the particular time or date at which local repository system172 received elements of replicated reference data 186 from the one ormore of notary systems 130 and store the received elements of replicatedreference data 186 within replicated data store 184.

Based on temporal data 124, local replication module 182 may performoperations that determine whether replicated reference data 186 reflectsa “current” composition of reference data store 112 and as such,represent a “current” snapshot of the reference data maintained withinreference data store 112. For example, local replication module 182 maydetermine a temporal interval between a current time or date (e.g., asdetermined by executed SaaS application 174) and the corresponding timeor date specified within obtained temporal data 124 (e.g., associatedwith the replicated reference data 186). In some instances, localreplication module 182 may establish that the one or more elements ofreplicated reference data 186 reflect the current composition ofreference data store 112 (and as such, represent the current snapshot ofreference data store 112) when the determined temporal interval fails toexceed a threshold interval.

If, for example, local replication module 182 were to establish that thedetermined temporal interval exceeds the threshold time period, executedSaaS application 174 may determine that the one or more elements ofreplicated reference data 186 maintained within replication data store184 no longer reflect the current composition of reference data store112. Based on the determination that the one or more elements ofreplicated reference data 186 fail to reflect the current composition ofreference data store 112, executed SaaS application 174 may performoperations (not illustrated in FIG. 3A) that generate a request foradditional elements of replication data representative of the currentcomposition of reference data store 112, and that cause local repositorysystem 172 to transmit the generated request across network 102 torepository system 110. As described herein, repository system 110 mayreceive the generated request, and in response to the receipt of thegenerated request (e.g., a detected occurrence of a correspondingreplication event), perform operations that initiate a replication ofthe elements of reference data currently maintained within referencedata store 112.

Alternatively, if local replication module 182 were to establish thatthe determined temporal interval fails to exceed the threshold timeperiod, executed SaaS application 174 may determine that replicatedreference data 186 reflects the current composition of reference datastore 112 and as such, represent the current snapshot of reference datastore 112. In response to the determination that replicated referencedata 186 reflects the current composition of reference data store 112,local replication module 182 may perform operations that generate one ormore elements of proposal data 328 that identify and characterize therequested addition of the updated phone number to the do-not-call listmaintained within replication data store 184. In some instances, theelements of proposal data 328 may include request 318 (e.g., thatincludes customer identifier 316, registry identifier 312, andmodification data 314 (e.g., the updated phone number “5559876543”),digital signature 320, and public key certificate 324.

Further, proposal data 328 may also include additional data, such asdata flag 330, that identifies a data type or characteristic associatedwith the requested addition, e.g., the updated phone number specifiedwithin modification data 314. Further, local replication module 182 mayalso package, into corresponding portions of proposal data 328, a systemidentifier 332 associated with local repository system 172, such as, butnot limited to, a network address of local repository system 172 (e.g.,an IP address, a MAC address, etc.) or an application cryptogramassociated with executed SaaS application 174. The disclosed embodimentsare, however, not limited to these examples of proposal data 328, and inother instances, proposal data 328 may include any additional oralternate data identifying or characterizing a requested, approved, orimplemented modification to the existing elements of reference datamaintained within reference data store 112, and replicated locallywithin replicated data store 184.

Using any of the exemplary processes described herein, local replicationmodule 182 also generate and apply a digital signature 334 to proposaldata 246 using a private cryptographic key associated with localrepository system 172, such as private cryptographic key 180. Localreplication module 182 may also perform operations that cause localrepository system 172 to broadcast proposal data 328, digital signature334, and a public key certificate 336 associated with local repositorysystem 172 or executed SaaS application 174 (e.g., that includes acorresponding public cryptographic key 338) across network 102 to one ormore of notary systems 130, including notary system 132. Further, insome instances (not illustrated in FIG. 3A), local replication module182 may also encrypt proposal data 328, digital signature 334, and/orpublic key certificate 336 using a public cryptographic key associatedwith one or more of notary systems 130, e.g., prior to transmissionacross network 102 by local repository system 172.

In some instances, and as described herein, the generation andapplication of digital signature 334 to proposal data 328 may enable oneor more of notary systems 130, such as notary system 132, to performoperations that, based on a validation of digital signature 334,authenticate an identity of local repository system 172 or executed SaaSapplication 174, and further, establish an integrity of the datamaintained within proposal data 328. In other instances, the generationand application of digital signature 334 to proposal data 328 may beindicative of an approval, of a consent, of executed SaaS application174 (and as such, of local repository system 172) to requested additionof the updated phone number to the do-not-call registry maintainedwithin replication data store 184 at local repository system 172.

Referring to FIG. 3B, local replication module 182 may also performoperations that provide modification data 314 (e.g., the updated phonenumber “5559876543”), customer identifier 316, data flag 330, andtemporal data 340 identifying a time or date associated with therequested addition to the do-not-call registry as inputs to local blockgeneration module 192 of executed SaaS application 174. In someinstances, executed local block generation module 192 may perform any ofthe exemplary processes described herein to generate an additionalelement 342 of local distributed ledger 294 that includes customeridentifier 316 and the requested addition to the do-not-call registry(e.g., the updated customer telephone number “5559876543,” as includedwithin modification data 314) and additionally, or alternatively,information representative of the updated customer telephone number,such as a cryptographic or non-cryptographic hash value. Additionalelement 342 may also include temporal data 340 and data flag 330, and insome examples, may be representative of a modified state of thereplicated reference data 186 that includes the requested addition tothe do-not-call registry maintained in reference data store 112 byrepository system 110. Executed local block generation module 192 mayalso perform any of the exemplary processes described herein to appendadditional element 342 to local distributed ledger 294 and to generate alatest, longest version of the immutable, cryptographically secure,local distributed ledger that includes additional element 342, e.g.,local distributed ledger 344.

Referring to FIG. 4A, a programmatic interface established andmaintained by each of the one or more of notary systems 130, such as API133 of notary system 132, may receive proposal data 328, digitalsignature 334, public key certificate 336 (which include correspondingpublic cryptographic key 338) from local repository system 172, and mayroute proposal data 328, digital signature 334, and public keycertificate 336 to executed verification and consent engine 134. Asdescribed herein, proposal data 328 may include, among other things,request 318, which corresponds to the request to add the updated phonenumber of user 201 (e.g., “5559876543”) to the do-not call registrymaintained locally within replicated data store 184, and as furthermaintained within reference data store 112. Further, and as describedherein, proposal data 328 may also include, but is not limited to,digital signature 320 applied to request 318 by executed mobile SaaSapplication 302, public key certificate 324 associated with mobile SaaSapplication 302 (including corresponding public cryptographic key 326),data flag 330 indicative of the requested additional of the updatedphone number to the do-not-call registry, and identifier 332 associatedwith local repository system 172, such as an IP or MAC address.

As described herein, request 318 may be generated by mobile SaaSapplication 302 executed by client device 202, (e.g., based on inputprovisioned by user 201), and approved by executed SaaS application 174.In some instances, request 318 may include, among other things, customeridentifier 316 that uniquely identifies user 201 within reference datastore 112 and replicated data store 184, registry identifier 312associated with the do-not-call registry within reference data store 112and replicated data store 184, and modification data 314 that specifiesthe requested addition to the do-not-call registry (e.g., the updatedphone number “5559876543”). The disclosed embodiments are, however, notlimited to these exemplary components of proposal data 328, and in otherinstances, proposal data 328 may include any additional or alternateelements of data that identify and characterize a proposed modificationof, update to, or addition to the elements of reference data maintainedwithin replicated data store 184 and reference data store 112, or thatestablish an approval or consent of local repository system 172 and/orexecuted mobile SaaS application 302 to the proposed modification, orthat establish an approval or a consent of executed mobile SaaSapplication 302 to the requested modification.

Executed verification and consent engine 134 may receive proposal data328, digital signature 334, and public key certificate 336, and in someinstances, may perform operations (not illustrated in FIG. 4A) thatdecrypt the encrypted portions of proposal data 328, digital signature334, and public key certificate 336 using a private cryptographic keyassociated with notary systems 130, such as private cryptographic key137 of notary system 132. Further, executed verification and consentengine 134 may also perform operations that validate digital signature334 using public cryptographic key 338 (e.g., as obtained from publickey certificate 336), and based on a successful validation of digitalsignature 334, executed verification and consent engine 134 mayauthenticate an identity of local repository system 172, and further,establish an integrity of the data maintained within proposal data 328.In some instances, a successful validation of digital signature 334 byexecuted verification and consent engine 134 may also be indicative ofan approval, of a consent, of local repository system 172 or executedSaaS application 174 to the requested addition of the updated phonenumber to the do-not-call registry maintained by replicated data store184.

Additionally or alternatively, executed verification and consent engine134 may also parse proposal data 328 to obtain request 318, digitalsignature 320, and public key certificate 324 of executed SaaSapplication 302 or client device 202, and may perform additionaloperations that validate digital signature 320 using publiccryptographic key 326, e.g., as obtained from public key certificate324. In some instances, and through a successful validation of applieddigital signature 320, applied digital signature 222 may not onlyauthenticate an identity of executed SaaS application 302 (and as such,or client device 202) and establish an integrity of request 318, butalso confirm an approval of, and a consent to, requested additional ofthe updated phone number to the do-not-call registry by executed mobileSaaS application 302, which generated request 318 in response to inputfrom user 201.

If, for example, executed verification and consent engine 134 wereunable to validate digital signature 334 or were unable to validatedigital signature 320, notary system 132 (and additional, or alternate,ones of notary systems 130) generate and transmit an error messagecharacterizing the failed validation across network 102 to localrepository system 172, and may discard proposal data 328, digitalsignature 334, and public key certificate 336. In other examples, andbased on the successful validation of digital signature 334 (andadditionally, or alternatively, of digital signature 320), executedverification and consent engine 134 may perform operations that provideproposal data 328 as an input to notarization management engine 252 ofnotary system 132 (and of additional, or alternate, ones of notarysystems 130). When executed by the one or more processors of notarysystem 132 (and each additional, or alternate, one of notary systems130), notarization management engine 252 may perform operations thatstore proposal data 328 within a portion one or more tangible,non-tangible memories or notary system 132, e.g., within a portion of anotarization queue 402 maintained within notary data store 136. In someinstances, notarization queue 402 may maintain one or more additionalelements of proposal data awaiting notarization through any of theexemplary, consensus-based notarization processes described herein, suchas, but not limited to, pending proposal data 404 and 406 of FIG. 4A.

Each of the queued elements of pending proposal data maintained withinnotarization queue 402, including pending proposal data 404 and pendingproposal data 406, may be associated with a corresponding modificationto the elements of reference data maintained within reference data store112, and may be generated by repository system 110, by local repositorysystem 172 executing SaaS application 174, or by one or more additionalcomputing systems using any of the exemplary processes described herein.Further, although not illustrated in FIG. 4A, each of the pendingelements of proposal data maintained within notarization queue 402 mayinclude a unique identifier of a customer associated with thecorresponding modification, update, or addition (e.g., customeridentifier 316 of proposal data 328), data identifying or characterizingthe corresponding modification, update, or addition (e.g., registryidentifier 312, modification data 314, or data flag 330 identifying orcharacterizing the addition of the updated customer phone call of thedo-not-call registry, as included within proposal data 328), and datathat identifies the computing system or device within environment 100that requested notarization of the corresponding modification, update,or addition (e.g., identifier 332 associated with local repositorysystem 172, as included within proposal data 328).

In some instances, executed notarization management engine 252 may alsoperform operations that prioritize each of the elements of pendingproposal data maintained within notarization queue 402 (includingproposal data 328, pending proposal data 404, and pending proposal data406) in accordance with one or more temporal, data-specific, or systemspecific prioritization factors. For example, executed notarizationmanagement engine 252 may perform operations that determine, for each ofthe queued elements of pending proposal data, a period of pendencywithin notarization queue 402 (e.g., based on temporal data stored inconjunction with the elements of pending proposal data in notarizationqueue 402, etc.), and that prioritize the queued elements of pendingproposal data based on the determined pendency periods, e.g., theelement of pending proposal data associated with a maximum pendencyperiod may be prioritized within notarization queue 402, etc.

In other examples, executed notarization management engine 252 mayperform operations that prioritize the queued elements of pendingproposal data based on, among other things, a particular element ofreference data associated with the corresponding modification, aparticular modification type, the computing system or device thatrequested the corresponding modification, update, or addition, or anyadditional, or alternate, prioritization factor appropriate to thequeued elements of pending proposal data. For instance, and in additionto, or as an alternate to, the temporal prioritization described herein,executed notarization management engine 252 may also prioritize thequeued elements of pending proposal data generated by repository system110 (e.g., that maintains reference data store 112) above those queuedelements of pending proposal data generated by other computing systemsor devices operating within environment 100 (e.g., local repositorysystems 172, etc.).

Referring back to FIG. 4A, executed notarization management engine 252may perform operations that load, from the one or more tangible,non-transitory memories of notary system 132, the latest, longestversion of the notarized distributed ledger, e.g., notarized distributedledger 272. As described herein, notarized distributed ledger 272 mayinclude smart contract elements 150, which include (e.g., record) one ormore elements of executable code, code modules, or application programs,such as distributed notarization module 152, along with correspondingelements of supporting data, such as notarization criteria 154. In someinstances, executed notarization management engine 252 may performoperations that access smart contract elements 150 of notarizeddistributed ledger 272, and that trigger an execution of distributednotarization module 152 by the one or more processors of notary system132, e.g., via a corresponding programmatic call, etc. Further, executednotarization management engine 252 may select one of the queued andprioritized elements of pending proposal data maintained withinnotarization queue 402, such as proposal data 328, and may provideproposal data 328 as an input to executed distributed notarizationmodule 152.

As described herein, the elements of code or software instructions andsupporting data, including distributed notarization module 152 andnotarization criteria 154, may collectively establish a distributednotarization contract within notarized distributed ledger 272. In someinstances, the distributed notarization contract may establish one ormore conditions that, when applied to proposal data 328 by one or moreof notary systems 130 (including notary system 132) through any of theexemplary consensus-based processes described herein, indicate whetherthe one or more of notary systems 130 should: (i) approve the requestedaddition of the updated phone number to the do-not-call registrymaintained within reference data store 112 (e.g., by repository system110 acting as the system of record) and record data representative ofthe approved addition within an additional element of notarizeddistributed ledger 272 (e.g., collectively, to notarize the requestedaddition of the updated phone number to the do-not-call registry); or,alternatively, (ii) reject the requested addition and notify therequesting computing system or device within environment 100 thatrequested the addition, e.g., local repository system 172. Throughcertain of these exemplary, consensus-based processes, theimplementation of the distributed notarization contract may prevent orminimize any instances of impermissible “double updates,” i.e.,simultaneous requests for distinct modifications, updates, or additionsto a single element of the reference data maintained within referencedata store 112, and may resolve or prioritize requests to modify theelements of reference data store 112 received sequentially fromcomputing systems or devices operating within environment 100.

Referring back to FIG. 4A, executed distributed notarization module 152may receive proposal data 328, and may parse proposal data 328 andobtain customer identifier 316 of user 201, registry identifier 312associated with the do-not-call registry, and modification data 314 thatspecifies the requested addition to the do-not-call registry (e.g., theupdated phone number “5559876543”). Executed distributed notarizationmodule 152 may also obtain, from proposal data 328, data flag 330indicative of the requested addition of the updated phone number to thedo-not-call registry and identifier 332 associated with local repositorysystem 172, such as an IP or MAC address of local repository system 172or the application cryptogram associated with executed SaaS application174.

Executed distributed notarization module 152 also access notarizationcriteria 154, e.g., as maintained within smart contract elements 150 ofnotarized distributed ledger 272. Based on one or more of extractedcustomer identifier 316, extracted registry identifier 312, extractedmodification data 314, extracted data flag 330, or extracted identifier332, executed distributed notarization module 152 select one or more ofthe discrete notification criteria, such as criterion 408, associatedwith proposal data 328 and as such, applicable to the notarization ofthe requested addition of the updated phone number to the do-not callregistry.

For example, selected criterion 408 may include an applicationcryptogram (or other element of cryptographic data) associated withexecuted SaaS application 174, or a network address associated withlocal repository system 172 (e.g., an IP or a MAC address), and based ona determined correspondence between extracted identifier 332 and theapplication cryptogram or network address included within criterion 408,executed distributed notarization module 152 may establish anapplicability of criterion 408 to the requested addition of the updatedphone number to the do-not-call registry. The disclosed embodiments are,however, not limited to processes that select criterion 408 based on anidentity of local repository system 174 or executed SaaS application174. In other instances, selected criterion 408 may also includeadditional information that associates criterion 408 with a particularcustomer (e.g., user 201), a particular element or particular elementsof reference data (e.g., the customer phone number, the do-not-callregistry, etc.), or with a particular operation on that element or thoseelements of reference data (e.g., the requested addition, etc.). Basedon a determined correspondence between the additional information and acorresponding one, or more, of extracted customer identifier 316,registry identifier 312, and extracted data flag 330, executeddistributed notarization module 152 may establish an applicability ofcriterion 408 to the requested addition of the updated phone number tothe do-not-call registry.

As illustrated in FIG. 4A, executed distributed notarization module 152may perform operations that obtain selected criterion 408 fromnotification criteria 154. Based on an application of selected criterion408 to portions of proposal data 328, notary system 132 (and additional,or alternate, ones of notary systems 130) to perform any of theconsensus-based operations described herein to: (i) approve therequested addition of the updated phone number to the do-not-callregistry and generate an additional element of notarized distributedledger 272 that includes information representative of the approvedaddition (e.g., to “notarize” the requested addition of the updatedphone number to the do-not-call registry); or alternatively, (ii) rejectthe requested addition of the update phone number to the do-not-callregistry and to transmit notification data indicative of the rejectedaddition to local repository system 172, e.g., for ingestion by executedSaaS application 174 and provisioning to client device 202.

For example, executed distributed notarization module 152 may parseselected criterion 408 to identify and obtain one or more elements ofpermissioning data, which indicate a permission granted to executed SaaSapplication 174, or local repository system 172, to modify all, or aselected portion of the elements of reference data maintained withinreference data store 112, e.g., those elements associated with thedo-not-call registry, In some instances, and based on registryidentifier 312, data flag 330, and/or identifier 332 extracted fromproposal data 328, executed distributed notarization module 152 maydetermine that proposal data 328 corresponds to an addition to thedo-not-call registry requested by local repository system 172 (orexecuted SaaS application 174). Further, based on portions ofpermissioning data, executed distributed notarization module 152 mayalso determine that local repository system 172 (or executed SaaSapplication 174) is permitted to modify the do-not-call registrymaintained within reference data store 112, and executed distributednotarization module 152 may approve the requested addition of theupdated phone number to the do-not-call registry. As illustrated in FIG.4A, executed distributed notarization module 152 may generateconfirmation data 410 indicative of the approved modification, and mayperform operations that route confirmation data 410 back to executednotarization management engine 252.

In other instances, selected criterion 408 may also include one or moreelements of the conditional data, which identify and characterize one ormore conditions imposed upon, or associated with, the notarization ofthe requested addition of the updated phone number to the do-not-callregistry, e.g., as characterized by proposal data 328. As describedherein, and based on the application of the one or more conditions toportions of proposal data 328, to one or more of the queued elements ofpending proposal data within notarization queue 402, and additionally,or alternatively, to one or more of the elements of notarizeddistributed ledger 284, executed distributed notarization module 152 maydetermine to approve and notarize, or to reject, the requested additionof the updated phone number to the do-not-call registry, and to generateand route confirmation data, e.g., confirmation data 410, indicative ofthe approval and notarization, or the rejection, back to executednotarization management engine 252.

For example, the conditional data may include information thatconditions the notarization of the requested addition of the updatedphone number to the do-not-call registry on a determination, by executeddistributed notarization module 152, that the requested additionalconflicts with neither: (i) a previously requested modification to theexisting elements of reference data maintained within reference datastore 112; nor (ii) a previously notarized modification to the existingelements of reference data maintained within reference data store 112.In some instances, and in accordance with the conditional data, executeddistributed notarization module 152 may perform operations that accessnotarization queue 402, and parse each of the queued elements of pendingproposal data (e.g., pending proposal data 404, pending proposal data406, etc.) to determine whether one or more of the queued elements ofpending proposal data include a customer identifier that references user201 or other information that references the do-not-call registrymaintained within reference data store 112 (e.g., a correspondingregistry identifier, etc.). Further, in accordance with the conditionaldata, executed distributed notarization module 152 may also performoperations the access one or more elements recorded onto notarizeddistributed ledger 284 (e.g., elements 260 and 282, as described herein,etc.), and that parse each of the accessed elements to determine whetherany of the accessed elements include notarization data referencing user201 (e.g., a corresponding customer identifier, etc.) and thedo-not-call registry maintained within reference data store 112 (e.g., acorresponding registry identifier, etc.).

In some examples, executed distributed notarization module 152 maydetermine that none of the queued elements of pending proposal datawithin notarization queue 402 reference portions of do-not-call registryassociated with user 201, and additionally, or alternatively, that noneof the additional recorded elements of notarized distributed ledger 284reference the portions of do-not-call registry associated with user 201.Based on this determination, executed distributed notarization module152 may establish that the requested addition of the updated phonenumber to the do-not-call registry, as specified within proposal data328, fails to represent an impermissible instance of a “doublemodification” that conflicts with previously requested modifications tothe do-not-registry maintained within reference data store 112. In someinstances, and in accordance with the conditional data, executeddistributed notarization module 152 may approve the requested additionof the updated phone number to the do-not-call registry, and maygenerate and route confirmation data, e.g., confirmation data 410, backto executed notarization management engine 252.

Alternatively, and based on the parsing of the queued elements ofpending proposal data within notarization queue 402, or on the parsingof the additional recorded elements of notarized distributed ledger 284,executed distributed notarization module 152 may confirm that at leastone of the queued elements of pending proposal data or the additionalrecorded elements reference the portions of do-not-call registryassociated with user 201. In some examples, and consistent with theconditional data, executed distributed notarization module 152 mayestablish that the requested addition of the updated phone number to thedo-not-call registry, as specified within proposal data 328, representsan impermissible instance of a “double modification” that conflicts withpreviously requested, or notarized, modifications to thedo-not-registry, and executed distributed notarization module 152 mayreject the requested addition of the updated phone number to thedo-not-call registry. In some instances, executed distributednotarization module 152 generate and route confirmation data, e.g.,confirmation data 410, back to executed notarization management engine252.

In other examples, the conditional data may also include one or moretemporal conditions that, when applied to proposal data 328 and to theat least one of the queued elements of pending proposal data or theadditional recorded elements that reference the portions of do-not-callregistry associated with user 201, enable executed distributednotarization module 152 to approve and notarize, or alternatively,reject, the requested addition of the updated phone number to theportions of the do-not-call registry associated with user 201 despitethe existence of the previously requested, or notarized, modificationsto the do-not-registry. For instance, the conditional data may specifythat the requested addition of the updated phone number to thedo-not-call registry does not represent an impermissible “doublemodification” when, among other things, a temporal interval between (i)a time of date associated with the requested addition (e.g., as includedwithin proposal data 328) and (ii) a time or date associated with eachof the queued elements of pending proposal data or the additionalrecorded elements that reference the portions of do-not-call registryassociated with user 201 exceeds a predetermined temporal interval.

For instance, and through any of the exemplary processes describedherein, executed distributed notarization module 152 may establish anadditional recorded element of notarized distributed ledger 284 includesnotarization data that references the portions of do-not-call registryassociated with user 201, and that the notarization data characterizes amodification notarized seventy-two hours prior to the generation ofproposal data 328 by executed SaaS application 174 (e.g., based ontemporal data within the additional recorded element and oncorresponding portions of proposal data 328). Further, in someinstances, executed distributed notarization module 152 may parse theconditional data to obtain the predetermined temporal intervalassociated with the requested addition to the do-not-call registry,e.g., twenty-four hours.

Based on a determination that the seventy-two-hour interval between thegeneration of proposal data 328 and the notarization of the previouslyrequested modification exceeds the predetermined temporal interval(e.g., the twenty-four-hour interval), executed distributed notarizationmodule 152 may establish that the requested addition of the updatedphone number to the do-not-call registry does not represent animpermissible “double modification” to reference data store 112, and mayperform any of the exemplary processes described herein to approve therequested addition and route one or more elements of confirmation databack to executed notarization management engine 252. In other instances,and based on a determination that the predetermined temporal intervalexceeds the interval between the generation of proposal data 328 and thenotarization of the previously requested modification, executeddistributed notarization module 152 may reject the requested addition tothe do-not-call registry (e.g., as an instance of an impermissible“double modification” to the do not call registry), and route one ormore additional elements of confirmation data back to executednotarization management engine 252.

The conditional data may also specify one or more velocity conditionsthat, among other things, impose limitations on a number ofmodifications to a particular element of the reference data during apredetermined temporal interval, or impose limitations on a number ofmodifications requested by a particular computing device or systemwithin environment 100 (e.g., local repository system 172, etc.) duringthat predetermined temporal interval. For instance, the conditional datamay include, for the particular element of the reference data, or forthe particular computing device or system, the predetermined temporalinterval and a maximum number of modifications permitted during thatprior temporal interval. Examples of the prior temporal interval mayinclude, but are not limited to, one hour, twenty-four hours, one week,or any additional or alternate temporal interval appropriate to theparticular element of the reference data to for the particular computingdevice or system.

In some instances, and based on the parsing of the queued elements ofpending proposal data within notarization queue 402, or on the parsingof the additional recorded elements of notarized distributed ledger 284,executed distributed notarization module 152, executed distributednotarization module 152 may determine a number of prior modifications tothe portion of the do-not-call registry associated with user 201 thatwere requested by local repository system 172 (e.g., via executed SaaSapplication 174) during the predetermined temporal interval, oralternatively, that were approved and notarized during the predeterminedtemporal interval. Further, executed distributed notarization module 152may also determine whether the addition of the updated phone number tothe portions of the do-not-call registry associated with user 201, asspecified within proposal data 328, would increase a total number ofmodifications during the predetermined temporal interval beyond themaximum number of permitted modifications to that portion of thedo-not-call registry, or alternatively, the maximum number ofmodifications requested by local repository system 172. Based on thisdetermination, executed distributed notarization module 152 may performoperations, consistent with the conditional data, that approve andnotarize the requested addition (e.g., when the total number ofmodification fail to exceed the maximum number of permitted and/orrequested modifications) or that reject the requested addition (e.g.,when the total number of modification exceeds the maximum number ofpermitted and/or requested modifications).

As described herein, notarization queue 402 may include multiple, queuedelements of pending proposal data that reference the portions ofdo-not-call registry associated with user 201, such as, but not limitedto, proposal data 328 and one or more additional queued elements ofpending proposal data. Additionally, and as described herein, proposaldata 328 may be associated with the requested additional of the updatedphone number of user 201 to the do-not call registry, and each of theone or more additional elements of pending proposal data may beassociated with a corresponding modification to the portions of thedo-not-call registry associated with user 201. In some examples,executed distributed notarization module 152 may perform operations thatdetermine an impact of the requested modification, update, or additionassociated with proposal data 328 and with each of the additional queuedelements on those portions of the do-not-call registry associated withuser 201 (e.g., on a status of user 201 within the do-not-callregistry).

Based on these determined impacts, and in accordance with theconditional data, executed distributed notarization module 152 mayperform further operations that approve and notarize, or reject, therequested addition of the update customer number to the do-not-callregistry. In some instances, and consistent with the conditional data,executed distributed notarization module 152 may elect to approve thenotarization of the requested addition of the update customer number tothe do-not call registry (e.g., as specified by proposal data 328) whenthat the requested addition is associated with a minimal, or leastrestrictive, impact on the status of user 201 within the do-not-callregistry, e.g., in comparison with the determined impacts of therequested modifications referenced by the additional queued elements ofpending proposal data.

For example, notarization queue 402 may include an additional queuedelement of pending proposal data (not illustrated in FIG. 4A) thatreferences a requested deletion of a phone number of user 201 from thedo-not call registry maintained within reference data store 112, and insome instances, and consistent with the conditional data, executeddistributed notarization module 152 may determine that requesteddeletion of the existing phone number of user 201 is associated with agreater impact of the status of user 201 within the do-not-call registrythan the requested addition of the updated customer number, as specifiedby proposal data 328. As such, executed distributed notarization module152 may establish that the requested addition is associated with aminimal, or least restrictive, impact on the status of user 201 withinthe do-not-call registry, and may perform any of the exemplary processesdescribed herein to approve the notarization of the requested additionand to route confirmation data indicative of the approved notarizationback to executed notarization management engine 252.

The disclosed embodiments are, however, not limited to these exemplaryprocesses for approving and notarizing proposed modifications, updates,or additions to the elements of reference data maintained withinreference data store 112, including but not limited to, the elements ofconfidential profile data associated with user 201 or those portions ofthe do-not-call registry associated with user 201, as described herein.In other examples, executed distributed notarization module 152 mayperform any additional, or alternate, operations that, consistent withpermissioning data, the conditional data, or other elements tosupporting data within smart contract elements 150, approve andnotarize, or reject, the requested modification, addition, or update tothe elements of confidential data specified within proposal data 246,proposal data 328, or other elements of proposal data broadcast tonotary systems 130 by repository system 110 or local repository system172.

Referring back to FIG. 4A, executed notarization management engine 252may receive, from executed distributed notarization module 152, one ormore elements of confirmation data 410 indicative of an approval andnotarization, or a rejection, of the requested addition of the updatecustomer number to those portions of the do-not-call registry associatedwith 201. In some instances, executed notarization management engine 252may process confirmation data 410 and determine that distributednotarization module 152 rejected the requested addition, e.g., using anyof the exemplary processes described herein. In response to thedetermined rejection, executed notarization management engine 252 mayperform operations (not illustrated in FIG. 4A) that cause notary system132 (or additional, or alternate, ones of notary system 30) to deleteproposal data 328 from notarization queue 402, and to generate andtransmit an error message across network 102 to local repository system172, which may receive the error message through a correspondingprogrammatic interface, such as API 176.

In some instances, at local repository system 172, executed local blockgeneration module 192 may perform any of the exemplary processesdescribed herein to generate an additional element of local distributedledger 344 that includes the error message, and to generate a latest,longest version of local distributed ledger 344 that includes theadditional element (not illustrated in FIG. 4A. In some instances, therecordation of the additional element onto the updated version of localdistributed ledger 344 may, in conjunction with previously recordedelement 342 (e.g., that characterizes the requested addition of theupdated customer number to the portions of the do-not-call registryassociated with user 101) establish a cryptographically secure andimmutable audit trail for the requested addition and the subsequentrejection of that requested addition. Local repository system 172 mayalso perform operations that route the error message across network 102to client device 202, e.g., for presentation within digital interface304 by executed mobile SaaS application 302 or by the executed webbrowser (also not illustrated in FIG. 4A).

In other examples, illustrated in FIG. 4A, executed notarizationmanagement engine 252 may process confirmation data 410 and determinethat distributed notarization module 152 approved the requestedaddition, e.g., using any of the exemplary processes described herein.In response to the determined approved, executed notarization managementengine 252 may perform operations that generate a notarization flag 412indicative of the approved notarization of the requested addition (e.g.,a value of unity, etc.) and that store notarization flag 412 within acorresponding portion of notarization queue 402, e.g., in associatedwith proposal data 328. Further, and based on the approval of therequested addition associated with proposal data 328, executednotarization management engine 252 may provide all, or a selectedportion, of proposal data 328 as an input to executed block generationengine 138. In some instances, executed block generation engine 138 mayperform any of the exemplary, consensus-based processes described hereinto generate an additional element 414 of notarized distributed ledger284 that includes (e.g., records) data representative of the notarizedaddition of the updated customer number to the portions of thedo-not-call registry maintained within reference data store 112 (e.g.,as associated with proposal data 328), to append additional element 414to notarized distributed ledger 284, and to generate a latest, longestversion of notarized distributed ledger 272, e.g., notarized distributedledger 426.

As illustrated in FIG. 4A, additional element 414 may include, amongother things, notarization data 416 that identifies, and characterizes,the notarized addition of the updated customer number to the do-not-callregistry maintained within reference data store 112. For example,notarization data 416 may include the now-notarized addition to thedo-not-call registry (e.g., the updated phone number of user 201,“5559876543,” as specified within modification data 314) andadditionally, or alternatively, data representative of the notarizedaddition, which as, but not limited to, a cryptographic ornon-cryptographic hash value. Additional element 414 may also include,among other things, customer identifier 316, registry identifier, andsystem identifier 332 that uniquely identifies local repository system172 or executed SaaS application 174, and temporal data 418, whichspecifies a time or date associated the approval of the notarizedaddition (e.g., by executed distributed notarization module 152) and/orthe generation of additional element 414 (e.g., by executed blockgeneration engine 138). Further, although not illustrated in FIG. 4A,executed block generation engine 138 or executed notarization managementengine 252 (e.g., based on input from executed block generation engine138) may store temporal data 418 within of notarization queue 402, e.g.,in associated with proposal data 328 and notarization flag 412.

Executed block generation engine 138 (and the block generation engineexecuted by additional ones of notary systems 130) may also perform anyof the exemplary processes described herein to generate and apply adigital signature 420 to all, or a selected portion, of notarizationdata 416 and temporal data 418, and to generate a hash value 422 basedon an application of one or more appropriate hash algorithms tonotarization data 416, temporal data 418, and digital signature 420 (andin some instances, to other elements of notarized distributed ledger272, such as a hash value representative included within a previouslyrecorded element of notarized distributed ledger 272, such as hash value146 of element 140). Executed block generation engine 138 may packagedigital signature 420 and hash value 422 into corresponding portions ofadditional element 414, e.g., in conjunction with the portions ofnotarization data 416 and temporal data 418. Notary system 132 mayperform operations, established through a distributed consensus amongadditional ones of notary systems 130, that generate and assign an index424 to additional element 414, that incorporate index 424 within acorresponding portion of additional element 414.

Notary system 132 may also broadcast notarized distributed ledger 426,which represents the latest, longest version of the immutable,cryptographically secure, notarized distributed ledger, across network102 to the additional ones of notary systems 130 operating withinenvironment 100. In some instances, notarized distributed ledger 426 ofFIG. 4A establish an immutable, time-evolving, and auditable record ofnot only the elements of reference data (e.g., as maintained withinreference data store 112) that are replicated to other computing systemsand devices operating within environment 100, but also subsequent,notarized modifications, updated, or additions to each of these elementsof reference data.

Referring to FIG. 4B, executed provisioning engine 156 (andadditionally, or alternatively, similar provisioning engines executed byother ones of notary systems 130) may perform operations that accessnotarization queue 402, and determine that proposal data 328 isassociated with notarization flag 412, which indicates of thenotarization of the requested addition of the updated phone number tothe do-not-call registry and confirms the recordation of datacharacterizing the notarized addition within notarized distributedledger 426. In some instances, executed provisioning engine 156 mayperform operations that extract proposal data 328 and temporal data 418(e.g., that specifies the time or date associated the approval of theaddition and/or the generation of additional element 414) fromnotarization queue 402, and that generate replication data 428 thatincludes all, or a selected portion, of proposal data 328 and temporaldata 418.

For example, executed provisioning engine 156 may obtain, from proposaldata 328, modification data 314 that specifies the now-notarizedaddition to the do-not-call registry (e.g., the updated phone number ofuser 201, “555987654”) and one or more of customer identifier 316 thatidentifies user 201 within the data records of reference data store 112and replicated data store 184, registry identifier 312 associated withthe do-not-call registry within reference data store 112 and replicateddata store 184, and system identifier 332 that identifies localrepository system 172 or executed SaaS application 174. In someinstances, executed provisioning engine 156 may package registryidentifier 312, modification data 314, and customer identifier 316 intocorresponding portions of replication data 428, along with temporal data418,

Further, executed provisioning engine 156 may also perform any of theexemplary processes described herein to generate and apply a digitalsignature 430 to replication data 428 using private cryptographic key137 associated with notary system 132 and other of notary systems 130.Executed provisioning engine 156 also perform operations that causenotary system 132 to broadcast replication data 428, applied digitalsignature 430, and public key certificate 164 associated with notarysystem 132 (which includes public cryptographic key 166) across network102 to local repository system 172 that executes SaaS application 174(e.g., that requested the now-notarized addition) and to repositorysystem 110 (e.g., that operates as a computing system of record andmaintains reference data store 112).

In some instances, and prior to transmission across network 102 to localrepository system 172, executed provisioning engine 156 may encryptreplication data 428, applied digital signature 430, and/or public keycertificate 164 using public cryptographic key 160 associated with SaaSapplication 174 executed at local repository system 172. Additionally,and prior to transmission across network 102 to repository system 110,executed provisioning engine 156 may also encrypt replication data 428,applied digital signature 430, and/or public key certificate 164 using apublic cryptographic key associated with the repository system 110, suchas public cryptographic key 129A.

Further, although not illustrated in FIG. 4B, and upon completion of theexemplary provisioning processes described herein, executed provisioningengine 156 may generate one or more elements of data, such as aprovisioning flag, indicative a successful provisioning of replicationdata 428 to local computing system 172. Executed provisioning engine 156may provide the provisioning flag as an input to executed blockgeneration engine 138, along with all, or a selected portion, ofreplication data 428, and executed block generation engine 138 mayperform any of the exemplary, consensus-based processes described hereinto generate an additional element of notarized distributed ledger 426that confirms the successful provisioning of replication data 428 tolocal computing system 172, and to append that generated additionalelement to notarized distributed ledger 426 and generate a latest,longest version of notarized distributed ledger 426.

Referring back to FIG. 4B, a programmatic interface established andmaintained by local repository system 172, such as API 176 associatedwith executed SaaS application 174, may receive replication data 428,digital signature 430, and public key certificate 164 (which includescorresponding public cryptographic key 166), and may route updatedreplication data 428, digital signature 430, and public key certificate164 to verification and consent module 178 of executed SaaS application174. As described herein, all, or a selected portion, of replicationdata 428, digital signature 430, and public key certificate 164 may beencrypted, and executed verification and consent module 178 may performoperations (not illustrated in FIG. 4B) that decrypt the encryptedportions of replication data 428, digital signature 430, and public keycertificate 164 using a private cryptographic key associated with SaaSapplication 174, such as private cryptographic key 180.

Executed verification and consent module 178 may also perform operationsthat validate digital signature 430 using public cryptographic key 166,e.g., as obtained from public key certificate 164. If, for example,executed verification and consent module 178 were unable to validatedigital signature 430, executed verification and consent module 178 maydiscard decrypted replication data 428, digital signature 430, andpublic key certificate 164. Alternatively, if executed verification andconsent module 178 were to validate decrypted digital signature 430,executed verification and consent module 178 may provide replicationdata 428 as an input to executed local replication module 182. In someinstances, executed local replication module 182 may perform any of theexemplary processes described herein to access replicated data store184, identify elements of replicated reference data 186 withinreplicated data store 184 that are referenced by decrypted replicationdata 428, and modify each of the one or more elements of replicatedreference data 186 in accordance with decrypted replication data 428.

For example, executed local replication module 182 may performoperations that parse replication data 428 to obtain customer identifier316, replicated data store 184, and modification data 314, whichincludes the notarized addition to the portions of the do-not-callregistry associated with user 201 (e.g., the updated phone number“5559876543”). Further, executed local replication module 182 may accessreplicated data store 184, and identify one or more data records 432that include, or reference, registry identifier 312 and as such, includeelements of reference data that establish the do-not-call registry.Executed local replication module 182 may also perform operations thatparse elements of reference data within data records 432 and identifyelements 434 of reference data associated with customer identifier 316,which correspond to the portion of the do-not-call registry associatedwith user 201.

In some instances, executed local replication module 182 may performoperations that modify the elements 434 of reference data within datarecords 432 to include all, or a selected portion of modification data314 (e.g., the updated customer telephone number “5559876543”), and assuch, augment the do-not-call list to include the updated number of user201 (e.g., to implement the notarized addition to the do-not-callregistry). In some instances, the exemplary operations performed byexecuted local replication module 182 to access replicated data store184, and to identify or parse one or more of data records 432, mayinclude one or more read operations on those portions of one or more thetangible, non-transitory memories associated with replicated data store184, and the exemplary operations performed by executed localreplication module 182 to include the updated phone number of user 201within data records 432 may include one or more write operations onthose portions of one or more the tangible, non-transitory memoriesassociated with replicated data store 184.

Executed local replication module 182 may also perform operations thatprovide modification data 314, which includes the notarized addition tothe portions of the do-not-call registry associated with user 201 (e.g.,the updated phone number “5559876543” added to data records 432), andtemporal data 418, which specifies which specifies a time or dateassociated the approval of the notarized addition and/or the generationof additional element 414, as inputs to executed local block generationmodule 192. In some instances, executed local block generation module192 may perform any of the exemplary, consensus-based processesdescribed herein to generate an additional element 436 of localdistributed ledger 344 that includes modification data 314, temporaldata 418, and/or information representative of the notarized addition(e.g., the updated phone number “5559876543” added to data records 432),such as a cryptographic or non-cryptographic hash value representativeof the updated phone number. In some examples, additional element 436may be representative of a modified state of the replicated referencedata 186 that includes the updated phone number of user 201 within theportions of the do-not-call registry associated with user 201. Further,executed local block generation module 192 may perform any of theexemplary, consensus-based processes described herein to appendadditional element 436 to local distributed ledger 344, and to generatea latest, longest version of the immutable, cryptographically secure,local distributed ledger that includes additional element 436, e.g.,local distributed ledger 438.

Further, in some examples, a programmatic interface established andmaintained by repository system 110, such as an application programminginterface (API) 440 associated with executable replication engine 118,may receive replication data 428, digital signature 430, and public keycertificate 164 (which includes corresponding public cryptographic key166), and may route updated replication data 428, digital signature 430,and public key certificate 164 to executable replication engine 118. Asdescribed herein, all, or a selected portion, of replication data 428,digital signature 430, and public key certificate 164 may be encrypted,and executable replication engine 118 may perform operations (notillustrated in FIG. 4B) that decrypt the encrypted portions ofreplication data 428, digital signature 430, and public key certificate164 using a private cryptographic key associated with repository system110 or executable replication engine 118, such as private cryptographickey 127.

Executed replication engine 118 may also perform operations thatvalidate digital signature 430 using public cryptographic key 166, e.g.,as obtained from public key certificate 164. If, for example, executedreplication engine 118 were unable to validate digital signature 430,executed replication engine 118 may perform additional operations (notillustrated in FIG. 4D) that cause repository system 110 to discarddecrypted replication data 428, digital signature 430, and public keycertificate 164. Alternatively, if executed replication engine 118 wereto validate successfully digital signature 430, executed replicationengine 118 may perform any of the exemplary processes described hereinto access reference data store 112, identify one or more elements ofreference data identified by, or referenced within, replication data428, and modify each of the one or more identified elements of referencedata in accordance with replication data 428.

For example, executed replication engine 118 may perform operations thatparse replication data 428 to obtain customer identifier 316, registryidentifier 312, and modification data 314, which includes the notarizedaddition to the portions of the do-not-call registry associated withuser 201 (e.g., the updated phone number “5559876543”). Further,executed replication engine 118 may access local reference data store112, and identify one or more data records 442 that include, orreference, registry identifier 312 and as such, include elements ofreference data that establish the do-not-call registry. Executedreplication engine 118 may also perform operations that parse elementsof reference data within data records 442 and identify elements 444 ofreference data associated with customer identifier 316, which correspondto the portion of the do-not-call registry associated with user 201.Executed replication engine 118 may perform additional operations thatmodify the elements 444 of reference data to include all, or a selectedportion of modification data 314 (e.g., the updated customer telephonenumber “5559876543”), and as such, augment the portion of thedo-not-call list to include the updated phone number of user 201 (e.g.,to implement the notarized addition to the do-not-call registry).

Through an application of one or more exemplary, consensus-basednotarization processes described herein to the proposed addition of theupdated phone number to the portion of the do-not-call registryassociated with user 201 (e.g., as specified by proposal data 328maintained within notarization queue 402), one or more of notary systems130, including notary system 132, may approve the proposed addition tothe do-not-call registry, and perform operations that record theapproved addition (e.g., the updated phone number of user 101), or datarepresentative of that proposed addition (e.g., a hash value, etc.)within an additional element of a cryptographically secure and immutablenotarized distributed ledger, e.g., within element 414 of notarizeddistributed ledger 426. Further, and as described herein, the one ormore of notary systems 130, including notary system 132, may performadditional operations that provision data identifying and characterizingthe now-notarized update (e.g., replication data 428) to not only anexecuted application program that requested the now-notarized update(e.g., SaaS application 174 executed at local repository system 172),but also to repository system 110, which maintains reference data store112.

The one or more of notary systems 130, including notary system 132, mayapply one or more of the exemplary, consensus-based notarizationprocesses described herein to each of the additional, or alternate,elements of pending proposal data queued within notarization queue 402,including, but not limited to, pending proposal data 404 and 406. Insome examples, and based on a successful outcome of the exemplary,consensus-based notarization processes, the one or more of notarysystems 130, including notary system 132, may provision replication dataidentifying and characterizing a notarized modification, update, oradditional to reference data store 112 associated with one or more ofthe elements of pending proposal data across network 102 to repositorysystem 110 (e.g., for inclusion within reference data store 112) andadditionally, or alternatively, to local repository system 172 (e.g.,for inclusion within replication data store 184). In some instances, theone or more of notary systems 130, including notary system 132, mayprovision the replication data associated with each of the queuedelements of pending proposal data on a streaming, element-by-elementbasis. In additional, or alternate, instances, the one or more of notarysystems 130, including notary system 132, may perform operations thatprovision the replication data associated with each of the queuedelements of pending proposal data on a batch basis (e.g., atpredetermined temporal intervals or in accordance with a predeterminedtemporal schedule), which may reduce traffic across network 102 andreduce an exposure of confidential data to potential attack orunauthorized access by malicious third parties.

Certain of these exemplary, consensus-based notarization processes mayconstrain an ability of multiple parties to simultaneously (or nearsimultaneously) propose updates to the elements of reference datamaintained by a system of record, reference data store 112 of repositorysystem 110. Further, one or more of these exemplary consensus-basednotarization processes, when implemented by one or more of notarysystems 130 in conjunction with repository system 110 and localrepository system 172, may establish and maintain a notarizeddistributed ledger that provides a cryptographically secure, immutable,and auditable record of not only each modification proposed byrepository system 110 or local repository system 172 to the elements ofreference data maintained within reference data store 112, but also ofan outcome of the consensus-based, notarization processing applied toeach of the proposed modifications, and, of a provisioning ofreplication characterizing notarized ones of the proposed modifications,updates, or additions to one or more computing systems operating withinenvironment 100, including, but not limited to, repository system 110and local repository system 172.

Further, and through an implementation of certain of the exemplaryprocesses described herein, repository system 110 and local repositorysystem 172 may establish and verify a consent and/or approval of acustomer to a requested modification, to the elements of reference datamaintained within reference data store 112 or replicated withinreplicated data store 184. For example, and as described herein, one ormore application programs executed at a device operable by the customer(e.g., mobile banking application 204 or mobile SaaS application 302executed by the one or more processors of client device 202) may performoperations that, based on a successful authentication of the user 201,apply a customer-specific digital signature to informationcharacterizing a requested modification, update, or addition to theelements of reference data maintained within reference data store 112(e.g., digital signature 222 applied to request 220 by executed mobilebanking application 204) or replicated within replicated data store 184(e.g., digital signature 320 applied to request 318 by executed mobileSaaS application 302).

As described herein, the application of digital signatures 222 and 320to respective ones of requests 220 and 318 may be indicative of aconsent, granted by user 201, to the requested modification, update, oraddition to the elements of reference data maintained within referencedata store 112 or replicated within replicated data store 184, andfurther, of an ownership by user 201 of the underlying elements ofreference data subject to modification (e.g., that user 201 is permittedto request the modification, update, or addition). Based on a validationof applied digital signatures 222 and 320, respective ones of repositorysystem 110 and local repository system 172 may perform any of theexemplary processes described herein to establish and verify the consentgranted by user 201 to the requested modification to the elements ofreference data. Responsive to the verification of the granted consent,and based on a determination that the requested modification, update, oraddition comports with one or more modification requirements orguidelines (e.g., a determination by executed SaaS application 174 toestablish that replicated reference data 186 corresponds to, or remains,a current snapshot of the elements of reference data maintained atrepository system 110 within reference data store 112), respective onesof repository system 110 and local repository system 172 may performoperations that apply an additional, system-specific digital signatureto corresponding ones of the requests and her applied customer-specificdigital signature (e.g., digital signature 250 applied to request 220and digital signature 222 by repository system 110, or digital signature334 applied to request 318 and digital signature 320 by local repositorysystem 172).

In some instances, the application of the system-specific digitalsignatures to both the information characterizing the requestedmodification to the elements of reference data and the correspondingcustomer-specific digital signature may be indicative of a consent., bya corresponding one of repository system 110 and local repository system172, to the modification to the elements of reference data requested bythe corresponding customer, e.g., user 201. Further, and as describedherein, one or more of notary systems 130, such as notary system 132,may receive the information characterizing the requested modification,update, or addition, and the corresponding customer- and system-specificdigital signatures from a corresponding one of repository system 110 andlocal repository system 172, and using any of the exemplary processesdescribed herein, may validate each of the customer- and system-specificdigital signatures prior to initiating the exemplary notarizationprocessing described herein. Based on a successful validation of boththe customer- and system-specific digital signatures, the one or more ofnotary systems 130, including notary system 132, may verify not only anintegrity of the received information characterizing the requestedmodification, update, or addition, but also that the requestedmodification represents, and is associated with, a valid requestapproved by user 201 (e.g., the customer) and a respective one ofrepository system 110 and local repository system 172, and that user 201possesses ownership sufficient to request the modification, update, oraddition to the underlying elements of reference data.

As described herein, repository system 110 may maintain, withinreference data store 112, elements of reference data identifying andcharacterizing customers of a financial institution and interactionsbetween these customers and the financial institution. Further, notarysystems 130 may perform any of the exemplary consensus-basednotarization processes described herein to establish and maintain anotarized distributed ledger that provides a cryptographically secure,immutable, and auditable record of each notarized modification, update,or addition to the elements of reference data maintained withinreference data store 112 on behalf of the financial institution. In someexamples, as described herein, reference data store 112 may representthe sole repository for reference data associated with the financialinstitution and its customers, and the notarized distributed ledgerestablished and maintained by notary systems 130 may represent the sole,auditable record of the notarized modifications, updated or additions tothe reference data.

In other examples, and consistent with the disclosed exemplaryembodiments, environment 100 may include one or more additionalrepository systems, each of which maintain elements of reference datawithin corresponding reference data stores. Further, each of theadditional repository systems may also be associated with acorresponding set of notary systems operating within environment 100,which may perform any of the exemplary, consensus-based notarizationprocesses described herein to establish and maintain an additionalnotarized distributed ledger that records notarized modifications,updates or additions to the reference data maintained at that additionalor alternate repository system. For example, the financial institutionmay include a plurality of discrete business units, and due to certainimposed regulatory or privacy policies, each of the business units maybe associated with a corresponding repository system maintainingelements of reference data within a corresponding,business-unit-specific reference data store, and corresponding notarysystems that establish and maintain a business-unit-specific notarizeddistributed ledger that records notarized modifications, updates oradditions to business-unit-specific reference data store.

As described herein, executed mobile banking application 204 may performany of the exemplary processes described herein to generate a request tomodify, update, or add to the elements of reference data maintained onbehalf of user 201 by the financial institution (e.g., request 220) andto apply a customer-specific digital signature to that request (e.g.,digital signature 222) indicative of a consent of user 201 to therequested modification, update, or addition and an ownership of theimpacted element of reference data. In some examples, executed mobilebanking application 204 may perform operations that cause client device202 to transmit the generated request and the applied, customer-specificdigital signature, among other things, to repository system 110, whichmay perform any of the exemplary processes described herein to verifythe customer-specific digital signature and as such, the consent andownership of user 201, to approve of and consent to the requestedmodification, to broadcast the request, the customer-specific digitalsignature, and an applied system-specific digital signature indicativeof the consent of repository system 110 across network 102 to notarysystems 130 for notarization and recordation within the correspondingnotarized distributed ledger, as described herein.

In other examples, executed mobile banking application 204 may alsoperform operations that cause client device 202 to broadcast, acrossnetwork 102, the generated request and the applied, customer-specificdigital signature, among other things, to each of the additionalrepository systems associated with the discrete business units of thefinancial institution. Each of these additional repository systems mayperform any of the exemplary processes described herein (e.g., withrespect to repository system 110) to verify the customer-specificdigital signature and as such, the consent and ownership of user 201, toapprove of and consent to the requested modification, to implement therequested modification, update, or addition within the elements ofreference data maintained within the corresponding,business-unit-specific reference data store, and to broadcast therequest, the customer-specific digital signature, and an appliedsystem-specific digital signature indicative of the consent ofrepository system 110 across network 102 to corresponding,business-unit-specific notary systems. The notary systems associatedwith each of the business units may also perform any of the exemplary,consensus-based notarization processes described herein (e.g., inreference to notary system 132) to validate the customer- andsystem-specific digital signatures, to notarize the requestedmodification, and to record that notarized modification within acorresponding element of the business-unit-specific notarizeddistributed ledger.

Further, in some examples, one or more of notary systems 130, such asnotary system 132, may perform processes that apply an additionaldigital signature to portions of notarization data characterizing anotarized modification to the elements of reference data maintainedwithin reference data store 112, and to broadcast the notarization dataand the additional applied digital signature across network 102 to eachof the additional business-unit-specific repository systems, or to eachof the additional, business-unit-specific notary systems. Theadditional, applied digital signature may be indicative of the approvalof the notarization of the modification, update, or addition to theelements of reference data, and the notarization data may include thecustomer- and system-specific digital signatures indicative of theconsent and ownership of the underlying customer (e.g., user 201) andthe consent of repository system 110. In some instances, thebusiness-unit-specific repository systems and/or thebusiness-unit-specific notary systems may validate thecustomer-specific, system-specific, and additional applied digitalsignature to verify the consent and ownership of user 101, the consentof repository system 110, and the approval and notarization of therequested modification, update, or addition by notary systems 130.Further, and based on a successful outcome of these validation andverification processes, the business-unit-specific repository systemsand notary systems may perform any of the exemplary processes describedherein, individually or collectively, to implement the requestedmodification within the elements of reference data maintained within thecorresponding, business-unit-specific reference data store, and tonotarize and record the modification within a corresponding element ofthe business-unit-specific notarized distributed ledger.

FIGS. 5A, 5B, and 5C are flowcharts of exemplary processes forreplicating elements of reference data using notarized distributedledgers, in accordance with the disclosed embodiments. For example, thecomputing system of record associated with a reference data store thatmaintains the elements of reference data, such repository system 110that maintains reference data store 112, may perform one or more of theexemplary steps of exemplary process 500, as described below inreference to FIG. 5A. Further, one or more computing systems configuredto perform consensus-based operations that establish, maintain, andbroadcast a notary distributed ledger, such as notary system 132, mayperform one or more of the exemplary steps of process 520, as describedbelow in reference to FIG. 5B. Additionally, in some examples, acomputing system that maintains locally replicated elements of referencedata within a replicated data store, such as local repository system172, may perform one or more of the exemplary steps of process 560, asdescribed below in reference to FIG. 5C.

Referring to FIG. 5A, repository system 110 may perform any of theexemplary processes described herein to detect an occurrence of an event(e.g., a “replication” event) that triggers a replication of all, or asubset, of the elements of reference data elements and correspondingcustomer identifiers maintained within reference data store 112 (e.g.,in step 502 of FIG. 5A). In response to the detected occurrence of thereplication event, repository system 110 may perform any of theexemplary processes described herein to parse reference data store 112and generate elements of status data 120 representative of a compositionof reference data store 112 during a particular temporal interval (e.g.,in step 504 of FIG. 5A). For example, and as described herein, thestatus data may be representative of a “snapshot” of the composition ofreference data store 112 during a current temporal interval (e.g., acurrent snapshot), and the elements of status data may include all, or aselected portion of the elements of reference data and associatedcustomer identifiers maintained within reference data store 112.Additionally, or alternatively, the elements of status data may includea hash value representative of all, or a selected portion, of thereference data elements and associated customer identifiers maintainedwithin reference data store 112, which may be computed by repositorysystem 110 through an application of a cryptographic ornon-cryptographic hash function to all, or the selected portion, of thereference data elements and associated customer identifiers.

In some examples, executed replication engine 118 may perform additionaloperations that generate a replication request that includes, but is notlimited to, the elements of status data, temporal data that specifies adate or time characterizing the current snapshot of reference data store112 represented by the elements of status data, and one or more uniqueidentifiers of repository system 110 and/or an application programexecuted by repository system 110 (e.g., in step 506 of FIG. 5A).Further, in some instances, repository system 110 may also performoperations that encrypt all or a portion of the replication request 122using, for example, a public cryptographic key associated with one ormore of the network-connected computing systems operating withinenvironment 100 (e.g., a public cryptographic key associated with one ormore of notary systems 130, including notary system 132).

Repository system 110 may also perform any of the exemplary processesdescribed herein to generate and apply a digital signature to thereplication request (e.g., in encrypted or unencrypted form) using acorresponding private cryptographic key (e.g., in step 508 of FIG. 5A).In some instances, repository system 110 may perform operations thatbroadcast the replication request (e.g., in encrypted or unencryptedform), the applied digital signature, and a public key certificate(which includes a corresponding public cryptographic key) across network102 to one or more of notary systems 130, including notary system 132(e.g., in step 510 of FIG. 5A). Exemplary process 500 is then completein step 512 of FIG. 5A.

Referring to FIG. 5B, the one or more of notary systems 130, includingnotary system 132, may receive the replication request (e.g., inencrypted or unencrypted form), the applied digital signature, and thepublic key certificate (e.g., in step 522 of FIG. 5B). In someinstances, notary system 132 (and additional, or alternate, ones ofnotary systems 130) may perform any of the exemplary processes describedherein to validate the applied digital signature using the publiccryptographic key maintained within the public key certificate (e.g., instep 524 of FIG. 5B). As described herein, and based on a successfulvalidation of the applied digital signature in step 524, notary system132 (and additional, or alternate, ones of notary systems 130) mayauthenticate an identity of repository system 110 (or the applicationprogram(s) executed at repository system 110), and further, establish anintegrity of the data maintained within the replication request.Further, a successful validation of the applied digital signature instep 524 may be indicative of an approval, or a consent, of repositorysystem 110 to the replication of the current snapshot of the compositionof reference data store 112, e.g., using any of the exemplary,consensus-based processes described herein.

If, for example, notary system 132 (and additional, or alternate, onesof notary systems 130) were unable to validate the applied digitalsignature (e.g., in step 524; NO), notary system 132 (and additional, oralternate, ones of notary systems 130) may decline to approve ornotarize the requested replication of the elements of reference datamaintained within reference data store 112 (e.g., in step 526 of FIG.5B). Further, notary system 132 (and additional or alternate ones ofnotary systems 130) may generate and transmit an error messagecharacterizing the failed validation across network 102 to repositorysystem 110, and may discard the replication request, the applied digitalsignature, and the public key certificate (e.g., in step 528 of FIG.5B). Exemplary process 520 is then complete in step 530.

Alternatively, if notary system 132 (and additional, or alternate, onesof notary systems 130) were to validate successfully the applied digitalsignature (e.g., in step 524; YES), notary system 132 (and additional,or alternate, ones of notary systems 130) may approve the requestedreplication of the elements of reference data maintained withinreference data store 112, and may store the replication request, theapplied digital signature, and the public key certificate within aportion one or more tangible, non-tangible memories (e.g., in step 532of FIG. 5B). As described herein, all or a selected portion of thereplication request may be encrypted (e.g., using the publiccryptographic key associated with the one or more of notary systems130), and in step 532, notary system 132 (and additional, or alternate,ones of notary systems 130) may perform any of the exemplary processesdescribed herein to decrypt the encrypted portions of the replicationrequest using a private cryptographic key associated with notary systems130, and store the now-decrypted portions of the replication requestwithin the one or more tangible, non-transitory memories (e.g., also instep 532 of FIG. 5B).

In some instances, notary system 132 (and additional, or alternate, onesof notary systems 130) may perform any of the exemplary, consensus-basedprocesses described herein to generate an element of a notarizeddistributed ledger (e.g., a ledger block) that includes or records all,or a selected portion, of the now-approved replication request, and togenerate a latest, longest version of that notarized distributed ledgerthat includes the generated element and as such, that reflects thecurrent composition of reference data store 112 maintained at repositorysystem 110 (e.g., in step 534 of FIG. 5B). By recording the now-approvedreplication request within the generated element of the latest, longestversion of the notarized distributed ledger (e.g., in step 534), notarysystem 132 (and additional, or alternate, ones of notary systems 130)may “notarize” the requested replication of the elements of referencedata maintained within reference data store 112, and may perform any ofthe exemplary processes described herein to provision portions of thenow-approved replication request, which establishes the current“snapshot” of reference data store 112, to one or more additionalcomputing systems operating within environment 100 permitted to operateon the elements of reference data maintained within reference data store112, such as, but not limited to local repository system 172 (e.g., insteps 536, 538, and 540 of FIG. 5B).

For example, notary system 132 (and additional, or alternate, ones ofnotary systems 130) may perform any of the exemplary processes describedherein to generate replication data that includes all, or a selectedpotion, of the now-approved replication request (e.g., in step 536 ofFIG. 5B), and to generate and apply a digital signature to thereplication data (in encrypted, or unencrypted, form) using the privatecryptographic key associated with notary systems 130 (e.g., in step 538of FIG. 5B). In some examples, notary system 132 (and additional, oralternate, ones of notary systems 130) may broadcast the replicationdata (in encrypted or unencrypted form), the applied digital signature,and a public key certificate associated with notary systems 130 (whichincludes a corresponding public cryptographic key) across network 102 tothe one or more additional computing systems permitted by repositorysystem 110 to operate on the elements of reference data maintainedwithin reference data store 112, such as local repository system 172(e.g., in step 540 of FIG. 5B). Exemplary process 520 is then completein step 542.

Referring to FIG. 5C, local repository system 172 may receive thereplication data (in encrypted or unencrypted form), the applied digitalsignature, and the public key certificate broadcast by one or more ofnotary systems 130 (e.g., in step 562 of FIG. 5C). In some instances,local repository system 172 may perform any of the exemplary processesdescribed herein to validate the applied digital signature using thepublic cryptographic key maintained within the public key certificate(e.g., in step 564 of FIG. 5C). If, for example, local repository system172 were unable to validate the applied digital signature (e.g., step564; NO), local repository system 172 may perform operations that causelocal repository system 172 to discard the replication data, the applieddigital signature, and the public key certificate (e.g., in step 566 ofFIG. 5C). Exemplary process 560 is then complete in step 568 of FIG. 5C.

Alternatively, and based on the successful validation of the digitalsignature (e.g., step 564; YES), local repository system 172 may verifythe integrity of the replication data and may establish that notarysystem 132 (or the additional, or alternate, ones of notary systems 130)represents a valid, trusted source for the replication data, and mayperform any of the exemplary processes described herein to decrypt thereplication data using a private cryptographic key associated with localrepository system 172 (e.g., in step 570 of FIG. 5C). In some examples,local repository system 172 may perform any of the exemplary processesdescribed herein to that store the decrypted replication data within aportion of a local replicated data store (e.g., in step 572 of FIG. 5C).

As described herein, the decrypted replication data may include theelements of status data (e.g., which includes all, or a selectedportion, of the reference data elements and associated customeridentifiers maintained within reference data store 112 of repositorysystem 110), the temporal data (e.g., which specifies the particulardata and time characterizing the current snapshot of reference datastore), and one or more unique identifiers associated with repositorysystem 110. In some instances, and in step 572 of FIG. 5C, localrepository system 172 may perform any of the exemplary processesdescribed herein to store the reference data element and the associatedcustomer identifiers (e.g., as replicated reference data) withincorresponding portions of the local replicated data store in conjunctionwith the temporal data.

Further, as illustrated in FIG. 5C, local repository system 172 may alsoperform any of the exemplary processes described herein to record all,or a selected portion, of the replicated reference data, or arepresentation of the portions of the replicated reference data (e.g., acryptographic or non-cryptographic hash value), and the temporal datawithin an element of a latest, longest version of a local distributedledger (e.g., in step 574 of FIG. 5C). Local repository system 172 maystore locally the latest, longest version of local distributed ledgerwithin one or more tangible, non-transitory memories, and in someinstances, may broadcast the latest, longest version of the localdistributed ledger across network 102 to one or more additionalcomputing systems operating within environment 100. Exemplary process560 is then complete in step 568.

FIGS. 6A, 6B, and 6C are flowcharts of exemplary processes fornotarizing a requested modification to elements of reference datamaintained at a computing system of record, or replicated locally at oneor more additional computing systems, using notarized distributedledgers, in accordance with the disclosed embodiments. For example, acomputing system that maintains locally replicated elements of referencedata within a corresponding replicated data store, such as localrepository system 172, may perform one or more of the exemplary steps ofprocess 600, as described below in reference to FIG. 6A. Further, one ormore computing systems configured to perform consensus-based operationsthat establish, maintain, and broadcast a notary distributed ledger,such as notary system 132, may perform one or more of the exemplarysteps of process 630, as described below in reference to FIG. 6B.Additionally, in some examples, a computing system that maintains thelocally replicated reference data within the replicated data store, suchas local repository system 172, may perform one or more of the exemplarysteps of process 660, as described below in reference to FIG. 6C.

Referring to FIG. 6A, local repository system 172 (or repository system110) may receive, from client device 202, a request to modify thelocally replicated elements of reference data within the correspondingreplicated data store, an applied, customer-specific digital signature,and a public key certificate associated with client device 202 (e.g., instep 602).

In some examples, the received request may include an identifier of acustomer associated with client device 202 (e.g., a login credential ofuser 201, etc.) and an identifier associated with client device 202(e.g., an IP or MAC address, an application cryptogram associated withmobile SaaS application 302, etc.). The received request may alsoinclude, but is not limited to, modification data that characterizes therequested modification (e.g., the updated phone number of user 201,registry identifier 312 of the do-not-call list, etc.), and additionaldata that identifies a data type, characteristic, or operationassociated with the requested modification (e.g., data type 330, etc.).In some instances, as described herein, all or a portion of the receivedrequest, the applied digital signature, and the public key certificatemay be encrypted by client device 202 (e.g., using a publiccryptographic key associated with local repository system 172), andlocal repository system 172 may perform operations that decrypt theencrypted portions of the received request, the applied digitalsignature, and the public key certificate using a corresponding privatecryptographic key.

Referring back to FIG. 6A, local repository system 172 may perform anyof the exemplary processes described herein to validate thecustomer-specific digital signature using a public cryptographic keyobtained from the received public key certificate (e.g., in step 604 ofFIG. 6A). Based on the failed validation of the customer-specificdigital signature (e.g., step 604; NO), local repository system 172 mayperform operations that generate and transmit an error messagecharacterizing the failed validation across network 102 to client device202, and may discard the received request, the applied digitalsignature, and the public key certificate (e.g., in step 606 of FIG.6A). Exemplary process 600 is then complete in step 608.

Alternatively, if local repository system 172 were to validatesuccessfully the customer-specific digital signature (e.g., step 604;YES), local repository system 172 may not only authenticate the identityof client device 202 (or executed mobile SaaS application 302) andestablish the integrity of the data maintained within the receivedrequest, but also confirm a consent of user 201 and executed mobile SaaSapplication 302 to the requested modification. In some instances, localrepository system 172 may perform any of the exemplary processesdescribed herein to establish whether the one or more elements ofreplicated reference data (e.g., as maintained within the replicate datastore) reflect a current composition of reference data store 112 and assuch, represent a current snapshot of the elements of reference datamaintained within reference data store 112 (e.g., in step 610).

For example, and as described herein, the one or more elements oflocally replicated reference data may be maintained within thereplicated data store in conjunction with temporal data, which mayspecify a time or date at which notary systems 130 provisioned the oneor more elements of replicated reference data using any of the exemplaryprocesses described herein. In some instances, in step 610, localrepository system 172 may obtain the temporal data from the replicateddata store, determine a temporal interval between a current time or dateand the corresponding time or date specified within obtained temporaldata, and establish that the one or more elements of replicatedreference data reflect the current composition of reference data store112 (and as such, represent the current snapshot of reference data store112) when the determined temporal interval fails to exceed a thresholdtime period.

If local repository system 172 were to establish that the one or moreelements of replicated reference data fail to reflect a currentcomposition of reference data store 112 (e.g., step 610; NO), localrepository system 172 may perform operations that generate and transmita replication request across network 102 to repository system 110 (e.g.,in step 612). In some instances, the receipt of the replication requestby repository system 110 may correspond to an occurrence of areplication event that, as described herein, causes repository system110 to perform any of the exemplary processes described herein toinitiate a replication of the elements of reference data maintainedwithin reference data store 112. As illustrated in FIG. 6A, exemplaryprocess 600 may pass back to step 606, and local repository system 172may generate and transmit an error message across network 102 to clientdevice 202, and may discard the received request, the applied digitalsignature, and the public key certificate. Exemplary process 600 is thencomplete in step 608.

Alternatively, if local repository system 172 were to establish that theone or more elements of replicated reference data reflect the currentcomposition of reference data store 112 (e.g., step 610; YES), localrepository system 172 may perform any of the exemplary processesdescribed herein to generate proposal data that identifies andcharacterizes the requested modification to the elements of replicatedreference data (e.g., in step 614 of FIG. 6A). In some instances, thegenerated proposal data may include all, or a selected portion, of thereceived request (e.g., the identifiers of the customer and of clientdevice 202, the modification data, the additional data that identifiesthe data type, characteristic, or operations associated with therequested modification, etc.) and the device-specific digital signature.

Further, in some examples, local repository system 172 may perform anyof the exemplary processes described herein to generate and apply asystem-specific digital signature to the proposal data using a privatecryptographic key associated with local repository system 172 (e.g., instep 616 of FIG. 6A). Local repository system 172 may also performoperations that broadcast the proposal data, system-specific digitalsignature 334, and a public key certificate associated with localrepository system 172 (e.g., that includes a corresponding publiccryptographic key) across network 102 to one or more of notary systems130, including notary system 132 (e.g., in step 618). Further, in someinstances (not illustrated in FIG. 6A), local repository system 172 mayalso encrypt the proposal data, the system-specific digital signature,and/or public key certificate 336 using a public cryptographic keyassociated with one or more of notary systems 130, e.g., prior totransmission by local repository system 172.

Further, local repository system 172 may also perform any of theexemplary processes described herein to record all, or a selectedportion, of the received request, or a representation of the portions ofthe received request (e.g., a cryptographic or non-cryptographic hashvalue), and temporal data characterizing a time or date of a receipt ofthe request by local repository system 172 within an element of alatest, longest version of a local distributed ledger (e.g., in step 618of FIG. 6A). Local repository system 172 may store locally the latest,longest version of local distributed ledger within one or more tangible,non-transitory memories. Exemplary process 600 is then complete in step608.

Referring to FIG. 6B, one or more of notary systems 130, includingnotary system 132, may receive the proposal data (e.g., in encrypted orunencrypted form), the system-specific digital signature, and the publickey certificate associated with local repository system 172 (e.g., instep 632 of FIG. 6B). In some examples, not illustrated in FIG. 6B,notary system 132 (and additional, or alternate, ones of notary systems130) may decrypt the encrypted portions of the proposal data, thesystem-specific digital signature, and the public key certificate usinga corresponding private cryptographic key.

Notary system 132 (and additional, or alternate, ones of notary systems130) may perform any of the exemplary processes described herein tovalidate the system-specific digital signature using the publiccryptographic key associated with local repository system 172, and tovalidate the customer-specific digital signature maintained within theproposal data using the public cryptographic key associated with clientdevice 202 (in step 634 of FIG. 6B). As described herein, and based on asuccessful validation of the system-specific digital signature in step634, notary system 132 (and additional, or alternate, ones of notarysystems 130) may authenticate an identity of local repository system 172(or the application program(s) executed at repository system 110, suchas SaaS application 174), and further, establish an integrity of thereceived proposal data. Further, a successful validation of the each ofthe customer- and system-specific digital signature in step 634 may beindicative of an approval, or a consent, of not only user 201 (or mobileSaaS application executed at client device 202, but also of localrepository system 172, to the requested modification of the elements ofreplicated reference data.

If, for example, notary system 132 (and additional, or alternate, onesof notary systems 130) were unable to validate the customer- orsystem-specific digital signatures (e.g., in step 634; NO), notarysystem 132 (and additional, or alternate, ones of notary systems 130)may decline to approve or notarize the requested modification to theelements of replicated reference data, and reject the proposal data(e.g., in step 636 of FIG. 5B). Further, notary system 132 (andadditional or alternate ones of notary systems 130) may generate andtransmit an error message characterizing the failed validation acrossnetwork 102 to local repository system 172, and may discard the proposaldata, the system-specific digital signature, and the public keycertificate (e.g., in step 638 of FIG. 6B). Exemplary process 630 isthen complete in step 640.

Alternatively, if notary system 132 (and additional, or alternate, onesof notary systems 130) were to validate successfully each of thecustomer- and system-specific digital signatures (e.g., in step 634;YES), notary system 132 (and additional, or alternate, ones of notarysystems 130) may perform any of the exemplary processes described hereinto add the received proposal data, along with corresponding temporaldata indicate of a time or date of receipt of the proposal data, into acorresponding portion of a notarization queue (e.g., in step 642). Insome instances, the queued elements of proposal data maintained withinthe notarization queue, including newly queued proposal data receivedfrom local repository system 172, may be prioritized, or ordered, inaccordance with one or more prioritization factors, such as, but notlimited to, the those described herein.

In some instances, notary system 132 (and additional, or alternate, onesof notary systems 130) may perform operations that select one of thequeued elements of proposal data within the notarization queue, andextract the selected element of proposal data from the notarizationqueue (e.g., in step 644 of FIG. 6B). The selected elements of proposaldata may, for example, represent a corresponding one of the queuedelements of proposal data characterized by an initial position, and amaximum priority, within the notarization queue. Further, notary system132 (and additional, or alternate, ones of notary systems 130) mayperform any of the exemplary processes described herein to approve, oralternatively, to reject, a proposed or requested modificationidentified and characterized by the selected element of proposal dataextracted from the notarization queue (e.g., in step 646 of FIG. 6B).

By way of example, and as described herein, notary system 132 (andadditional, or alternate, ones of notary systems 130) may performoperations in step 646 that that load, from one or more tangible,non-transitory memories, a latest, longest version of the notarizeddistributed ledger. As described herein, the notarized distributedledger may include one or more smart contract elements, which include orrecord executable code, code modules, or application programs (e.g.,distributed notarization module 152) along with corresponding elementsof supporting data, such as notarization criteria 154 described herein.In some instances, and using any of the exemplary processes describedherein, notary system 132 (and additional, or alternate, ones of notarysystems 130) may execute the code, code modules, or applicationprograms, and the executed code, code modules, or application programsmay identify one or more of the recorded notarization criteriaapplicable to the selected element of proposal data (e.g., criterion408), and may apply the one or more identified notarization criteria tothe selected element of proposal data (e.g., also in step 646). Based onthe application of the one or more identified notarization criteria tothe selected element of proposal data, notary system 132 (andadditional, or alternate, ones of notary systems 130) may determinewhether to approve and notarize the modification associated withselected element of proposal data or alternatively, to reject themodification (e.g., also in step 646).

If, for example, notary system 132 (and additional, or alternate, onesof notary systems 130) were to reject the modification associated withselected element of proposal data (e.g., step 646; NO), notary system132 (and additional, or alternate, ones of notary systems 130) maydelete the selected element of proposal data from the notarization queue(e.g., in step 648 of FIG. 6A), and may generate and transmit an errormessage across network 102 to local repository system 172 (e.g., in step638 of FIG. 6B). Alternatively, if notary system 132 (and additional, oralternate, ones of notary systems 130) were to approve the modificationassociated with selected element of proposal data (e.g., step 646; YES),notary system 132 (and additional, or alternate, ones of notary systems130) may perform any of the exemplary processes described herein togenerate a notarization flag indicative of the approved modification andthat store the notarization flag within the notarization queue inassociation with the selected element of proposal data (e.g., in step650 of FIG. 6A). In some examples, notary system 132 (and additional, oralternate, ones of notary systems 130) may perform any of the exemplary,consensus-based processes described herein to generate an element of anotarized distributed ledger (e.g., a ledger block) that includes orrecords notarization data characterizing the approved modification tothe replicated reference data, and to generate a latest, longest versionof that notarized distributed ledger that includes the generated element(e.g., in step 652 of FIG. 6B).

For example, in step 652, notary system 132 (and additional, oralternate, ones of notary systems 130) may perform any of the exemplary,consensus-based processes described herein to access a prior version ofthe notarized distributed ledger (e.g., as maintained locally within theone or more tangible, non-transitory memories) and to append thegenerated element to that prior version to generate the latest, longestversion of the notarized distributed ledger. In some instances, byrecording the now-approved modification, e.g., as proposed by localrepository system 172, notary system 132 (and additional, or alternate,ones of notary systems 130) may “notarize” the proposed modification tothe replicated reference data, and provision data indicative of thenotarized modification to not only local computing system 172 (whichmaintains the replicated reference data within a correspondingreplicated data store), but also to repository system 110 (whichmaintains reference data store 112) and to additional or alternatecomputing systems permitted to replicate the reference data maintainedwithin reference data store 112.

Referring back to FIG. 6B, notary system 132 (and additional, oralternate, ones of notary systems 130) may parse the notification queueto determine whether additional queued elements of proposal data requireprocessing (e.g., in step 654 of FIG. 6B). If, for example, notarysystem 132 (and additional, or alternate, ones of notary systems 130)were to determine that additional queued elements of proposal datarequire processing (e.g., step 654; YES), exemplary process 630 may passback to step 644, and notary system 132 (and additional, or alternate,ones of notary systems 130) may select an additional one of the queuedelements of proposal data for processing and notarization using any ofexemplary processes described herein. Alternatively, if no furtheradditional queued elements of proposal data require processing (e.g.,step 654; NO), notary system 132 (and additional, or alternate, ones ofnotary systems 130) may perform any of the exemplary processes describedherein to provision identify, within the notarization queue, each of thequeued elements of proposal data associated with a correspondingnotarization flag (e.g., “notarized” elements of proposal data), and tobroadcast elements of provisioning data identifying and characterizingthe modifications associated with each of the notarized elements ofproposal data, a respective, notary-specific digital signature, and apublic key certificate of notary systems 130 to local repository system172, to repository system 110, and further, to additional, or alternate,computing systems permitted to replicate the reference data maintainedwithin reference data store 112 (e.g., in step 656 of FIG. 6B).

As described herein, the one or more of notary systems 130, includingnotary system 132, may provision the digitally signed elements ofprovisioning data associated with each of the notarized elements ofpending proposal data on a streaming, element-by-element basis. Inadditional, or alternate, instances, the one or more of notary systems130, including notary system 132, may perform operations that provisionthe digitally signed elements of provisioning data associated with eachof the notarized elements of pending proposal data on a batch basis(e.g., at predetermined temporal intervals or in accordance with apredetermined temporal schedule), which may reduce traffic acrossnetwork 102 and reduce an exposure of confidential data to potentialattack or unauthorized access by malicious third parties. In someexamples, and prior to transmission across network 102 to the localrepository system 172, repository system 110, or the one or moreadditional computing systems, notary system 132 (and additional, oralternate, ones of notary systems 130) may perform any of the exemplaryprocesses described herein to encrypt each of the digitally signedelements of provisioning data using a public cryptographic key (or otherencryption key) appropriate to corresponding ones of local repositorysystem 172, repository system 110, or the one or more additionalcomputing systems.

In some examples, notary system 132 (and additional, or alternate, onesof notary systems 130) may perform operations that generate one or moreelements of data, such as a provisioning flag, indicative a successfulprovisioning of each of the digitally signed elements of provisioningdata to the corresponding ones of local repository system 172,repository system 110, or the one or more additional computing systems,and may perform any of the exemplary consensus-based processes describedherein to record the provisioning flags within one or more elements of alatest, longest version of the notarized distributed ledger (e.g., instep 658 of FIG. 6B). Exemplary process 630 is then complete in step640.

Referring to FIG. 6C, local repository system 172 may receive an elementof provisioning data (in encrypted or unencrypted form), thenotary-specific digital signature, and the public key certificatebroadcast by one or more of notary systems 130, such as notary system132 (e.g., in step 662 of FIG. 6C). As described herein, the element ofprovisioning data may be associated with a modification to thereplicated reference data previously proposed by local repository system172 using any of the exemplary processes described herein, and theelement of provisioning data may confirm an approval and a notarizationof the proposed modification by the one or more of notary systems 130using any of the exemplary processes described herein.

In some instances, local repository system 172 may perform any of theexemplary processes described herein to validate the notary-specificdigital signature using the public cryptographic key maintained withinthe public key certificate (e.g., in step 664 of FIG. 6C). If, forexample, local repository system 172 were unable to validate the applieddigital signature, local repository system 172 may perform operationsthat cause local repository system 172 to discard the element ofprovisioning data (in encrypted or unencrypted form), the applieddigital signature, and the public key certificate (e.g., in step 666 ofFIG. 6C). Exemplary process 660 is then complete in step 668 of FIG. 6C.

Alternatively, and based on the successful validation of thenotary-specific digital signature, local repository system 172 mayverify the integrity of the element of provisioning data and mayestablish that notary system 132 (or the additional, or alternate, onesof notary systems 130) represents a valid, trusted source for theprovisioning data, and may perform any of the exemplary processesdescribed herein to decrypt the provisioning data using a privatecryptographic key associated with local repository system 172 (e.g., instep 670 of FIG. 6C). In some examples, local repository system 172 mayperform any of the exemplary processes described herein to access theelements of replicated reference data maintained within the replicateddata store, to identify at least one of those elements impacted by thenotarized modification characterized by the decrypted element ofprovisioning data, and to modify the at least one identified element ofthe replicated reference data in accordance with the notarizedmodification (e.g., in step 672 of FIG. 6C).

Further, as illustrated in FIG. 6C, local repository system 172 may alsoperform any of the exemplary processes described herein to record atleast a portion of the element of provisioning data that characterizesthe notarized modification to the replicated reference data, or arepresentation of that notarized modification (e.g., a cryptographic ornon-cryptographic hash value), and temporal data specifying a time ordate associated with the notarized modification, within an element of alatest, longest version of a local distributed ledger (e.g., in step 674of FIG. 6C). Local repository system 172 may store locally the latest,longest version of local distributed ledger within one or more tangible,non-transitory memories, and in some instances, may broadcast thelatest, longest version of the local distributed ledger across network102 to one or more additional computing systems operating withinenvironment 100. Exemplary process 660 is then complete in step 668.

c. Exemplary Computing Architectures

Embodiments of the subject matter and the functional operationsdescribed in this specification can be implemented in digital electroniccircuitry, in tangibly-embodied computer software or firmware, incomputer hardware, including the structures disclosed in thisspecification and their structural equivalents, or in combinations ofone or more of them. Exemplary embodiments of the subject matterdescribed in this specification, including replication engine 118, SaaSapplication 174, application programming interfaces (APIs) 133, 176,230, and 440, verification and consent engine 134, block generationengine 138, distributed notarization module 152, provisioning engine156, verification and consent module 178, local replication module 182,local block generation module 192, mobile banking application 204,verification and consent engine 232, management engine 238, notarizationmanagement engine 252, mobile SaaS application 302, can be implementedas one or more computer programs, i.e., one or more modules of computerprogram instructions encoded on a tangible non-transitory programcarrier for execution by, or to control the operation of, a dataprocessing apparatus (or a computer system or a computing device).

Additionally, or alternatively, the program instructions can be encodedon an artificially generated propagated signal, such as amachine-generated electrical, optical, or electromagnetic signal that isgenerated to encode information for transmission to suitable receiverapparatus for execution by a data processing apparatus. The computerstorage medium can be a machine-readable storage device, amachine-readable storage substrate, a random or serial access memorydevice, or a combination of one or more of them.

The terms “apparatus,” “device,” and “system” refer to data processinghardware and encompass all kinds of apparatus, devices, and machines forprocessing data, including, by way of example, a programmable processorsuch as a graphical processing unit (GPU) or central processing unit(CPU), a computer, or multiple processors or computers. The apparatus,device, or system can also be or further include special purpose logiccircuitry, such as an FPGA (field programmable gate array) or an ASIC(application-specific integrated circuit). The apparatus, device, orsystem can optionally include, in addition to hardware, code thatcreates an execution environment for computer programs, such as codethat constitutes processor firmware, a protocol stack, a databasemanagement system, an operating system, or a combination thereof.

A computer program, which may also be referred to or described as aprogram, software, a software application, a module, a software module,a script, or code, can be written in any form of programming language,including compiled or interpreted languages, or declarative orprocedural languages, and it can be deployed in any form, including as astand-alone program or as a module, component, subroutine, or other unitsuitable for use in a computing environment. A computer program may, butneed not, correspond to a file in a file system. A program can be storedin a portion of a file that holds other programs or data, such as one ormore scripts stored in a markup language document, in a single filededicated to the program in question, or in multiple coordinated files,such as files that store one or more modules, sub-programs, or portionsof code. A computer program can be deployed to be executed on onecomputer or on multiple computers that are located at one site ordistributed across multiple sites and interconnected by a communicationnetwork.

The processes and logic flows described in this specification can beperformed by one or more programmable computers executing one or morecomputer programs to perform functions by operating on input data andgenerating output. The processes and logic flows can also be performedby, and apparatus can also be implemented as, special purpose logiccircuitry, such as an FPGA (field programmable gate array), an ASIC(application-specific integrated circuit), one or more processors, orany other suitable logic.

Computers suitable for the execution of a computer program include, byway of example, general or special purpose microprocessors or both, orany other kind of central processing unit (CPU). Generally, a CPU willreceive instructions and data from a read-only memory or a random-accessmemory or both. Further, a computer may include a CPU for performing orexecuting instructions and one or more memory devices for storinginstructions and data. In some instances, a computer will also include,or be operatively coupled to receive data from or transfer data to, orboth, one or more mass storage devices for storing data, such asmagnetic, magneto-optical disks, or optical disks. Moreover, a computercan be embedded in another device, such as a mobile telephone, apersonal digital assistant (PDA), a mobile audio or video player, a gameconsole, a Global Positioning System (GPS) receiver, or a portablestorage device, such as a universal serial bus (USB) flash drive.

Computer-readable media suitable for storing computer programinstructions and data include all forms of non-volatile memory, mediaand memory devices, including by way of example semiconductor memorydevices, such as EPROM, EEPROM, and flash memory devices; magneticdisks, such as internal hard disks or removable disks; magneto-opticaldisks; and CD-ROM and DVD-ROM disks. The processor and the memory can besupplemented by, or incorporated in, special purpose logic circuitry.

To provide for interaction with a user, embodiments of the subjectmatter described in this specification can be implemented on a computerhaving a display unit, such as a CRT (cathode ray tube) or LCD (liquidcrystal display) monitor, a TFT display, or an OLED display, fordisplaying information to the user and a keyboard and a pointing device,such as a mouse or a trackball, by which the user can provide input tothe computer. Other kinds of devices can be used to provide forinteraction with a user as well; for example, feedback provided to thecustomer can be any form of sensory feedback, such as visual feedback,auditory feedback, or tactile feedback; and input from the user can bereceived in any form, including acoustic, speech, or tactile input. Inaddition, a computer can interact with a user by sending documents toand receiving documents from a device that is used by the customer; forexample, by sending web pages to a web browser on a customer's device inresponse to requests received from the web browser.

Implementations of the subject matter described in this specificationcan be implemented in a computing system that includes a back-endcomponent, such as a data server, or that includes a middlewarecomponent, such as an application server, or that includes a front-endcomponent, such as a computer having a graphical user interface or a Webbrowser through which a customer can interact with an implementation ofthe subject matter described in this specification, or any combinationof one or more such back-end, middleware, or front-end components. Thecomponents of the system can be interconnected by any form or medium ofdigital data communication, such as a communication network. Examples ofcommunication networks include a local area network (LAN) and a widearea network (WAN), such as the Internet.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other. In someimplementations, a server transmits data, such as an HTML page, to acustomer device, such as for purposes of displaying data to andreceiving customer input from a customer interacting with the customerdevice, which acts as a client. Data generated at the customer device,such as a result of the customer interaction, can be received from thecustomer device at the server.

While this specification includes many specifics, these should not beconstrued as limitations on the scope of the exemplary embodiments or ofwhat may be claimed, but rather as descriptions of features specific toparticular embodiments of the invention. Certain features that aredescribed in this specification in the context of separate exemplaryembodiments may also be implemented in combination in a single exemplaryembodiment. Conversely, various features that are described in thecontext of a single exemplary embodiment may also be implemented inmultiple exemplary embodiments separately or in any suitablesub-combination. Moreover, although features may be described above asacting in certain combinations and even initially claimed as such, oneor more features from a claimed combination may in some cases be excisedfrom the combination, and the claimed combination may be directed to asub-combination or variation of a sub-combination.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processingmay be advantageous. Moreover, the separation of various systemcomponents in the embodiments described above should not be understoodas requiring such separation in all exemplary embodiments, and it shouldbe understood that the described program components and systems maygenerally be integrated together in a single software product orpackaged into multiple software products.

In this application, the use of the singular includes the plural unlessspecifically stated otherwise. In this application, the use of “or”means “and/or” unless stated otherwise. Furthermore, the use of the term“including,” as well as other forms such as “includes” and “included,”is not limiting. In addition, terms such as “element” or “component”encompass both elements and components comprising one unit, and elementsand components that comprise more than one subunit, unless specificallystated otherwise. The section headings used herein are fororganizational purposes only, and are not to be construed as limitingthe described subject matter.

What is claimed is:
 1. An apparatus, comprising: a memory storinginstructions; a communications interface; and at least one processorcoupled to the communications interface and the memory, the at least oneprocessor being configured to execute the instructions to: receive, froma first computing system via the communications interface, a firstrequest to modify reference data maintained at a second computingsystem; approve the first requested modification to the reference databased on a notarization criterion maintained within an element of adistributed ledger, and perform operations that record notarization datacharacterizing the approved modification within an additional element ofthe distributed ledger; and transmit the notarization data to the firstcomputing system via the communications interface, the notarization datacausing an application program executed by the first computing system tomodify local reference data in accordance with the notarization data. 2.The apparatus of claim 1, wherein the at least one processor is furtherconfigured to execute the instructions to: receive, from the firstcomputing system via the communications interface, a first digitalsignature applied to the first request, the first digital signaturebeing generated by the first computing system; approve the firstrequested modification to the reference data based on a validation ofthe first digital signature, and based on the notarization criterion. 3.The apparatus of claim 2, wherein: the first request comprises a seconddigital signature generated by a device in communication with the firstcomputing system; and the at least one processor being configured toexecute the instructions to approve the first requested modification tothe reference data based on a validation of the second digitalsignature, based on the validation of the first digital signature, basedon the validation of the second digital signature, and based on thenotarization criterion.
 4. The apparatus of claim 1, wherein: the firstrequest comprises an identifier of an element of the reference datamaintained at the second computing system, the requested firstmodification, and first temporal data associated with the requestedfirst modification; the at least one processor is further configured toexecute the instructions to obtain second requests to modify thereference data maintained at the second computing system, each of thesecond requests comprising second temporal data associated with acorresponding one of the second requested modifications.
 5. Theapparatus of claim 4, wherein the at least one processor is furtherconfigured to execute the instructions to approve the first requestedmodification based on a determination that each of the second requestsfails to include the identifier.
 6. The apparatus of claim 4, wherein:the notarization criterion comprises a threshold temporal interval; andthe at least one processor is further configured to execute theinstructions to: when at least one of the second requests includes theidentifier of the element of reference data. determine (i) a firstrequest time associated with the first request based on the firsttemporal data and (ii) a second request time associated with the atleast one second request based on the corresponding second temporaldata; and approve the first requested modification when a temporaldifference between the first and second request times exceeds thethreshold temporal interval.
 7. The apparatus of claim 4, wherein: thenotarization criterion comprises a threshold request number and acorresponding temporal interval; the at least one processor is furtherconfigured to execute the instructions to approve the first requestedmodification when at least one of: a number of the first and secondrequests that include the identifier of the element of reference datafails to exceed the threshold request number during the correspondingtemporal interval; or an additional number of the first and secondrequests that include a system identifier of the first computing systemfails to exceed the threshold request number during the correspondingtemporal interval.
 8. The apparatus of claim 4, wherein: thenotarization criterion comprises permissioning data associated with atleast one of the first computing system or the second computing system;and the at least one processor is further configured to execute theinstructions to approve the first requested modification based on thepermissioning data.
 9. The apparatus of claim 8, wherein the at leastone processor is further configured to execute the instruction to:receive, from the second computing system via the communicationsinterface, a third request to modify one or more elements of thereference data; approve the third requested modification based on thepermissioning data, and perform operations that record additionalnotarization data characterizing the third requested modification withina further element of the distributed ledger; and transmit the additionalnotarization data to the first computing system via the communicationsinterface, the additional notarization data causing the applicationprogram executed by the first computing system to modify the localreference data in accordance with the additional notarization data. 10.The apparatus of claim 4, wherein: the first request comprises a firstidentifier of an element of the reference data maintained at the secondcomputing system and a second identifier of the first computing system;and the at least one processor is further configured to execute theinstructions to: load at least the element of the distributed ledgerfrom the memory, the element of the first distributed ledger comprisinga plurality of candidate notification criteria; based on at least one ofthe first identifier or the second identifier, determine that acorresponding one of the candidate notification criteria is associatedwith the first request; and establish the corresponding one of thecandidate notification criteria as the notification criterion.
 11. Theapparatus of claim 4, wherein the second requests comprise at least oneof a queued request to modify the reference data maintained at the firstcomputing system, or a notarized request to modify the reference datamaintained at the first computing system.
 12. The apparatus of claim 1,wherein: the element of the distributed ledger comprises additionalinstructions; and the at least one processor is further configured toexecute the additional instructions to approve the first requestedmodification to the reference data based on the notarization criterion.13. The apparatus of claim 1, wherein the at least one processor isfurther configured to execute the instructions to: receive, from thesecond computing system via the communications interface, a request toreplicate the reference data maintained at the second computing system;approve the replication request, and perform operations that recordreplication information characterizing the approved replication requestwithin a further element of the distributed ledger; and transmit thereplication data to the first computing system via the communicationsinterface, the replication data causing the application program executedby the first computing system to store at least a portion of thereplication information within a replicated data store.
 14. Theapparatus of claim 1, wherein the at least one processor is furtherconfigured to execute the instructions to: generate confirmation dataindicative of the transmission of the notarization data to the firstcomputing system; and perform operations that record the confirmationdata within a further element of the distributed ledger.
 15. Acomputer-implemented method, comprising: receiving, using at least oneprocessor, a request from a first computing system to modify referencedata, the reference data being maintained at a second computing system;using the at least one processor, approving the requested modificationto the reference data based on a notarization criterion maintainedwithin an element of a distributed ledger, and perform operations thatrecord notarization data characterizing the approved modification withinan additional element of the distributed ledger; and transmitting, usingthe at least one processor, the notarization data to the first computingsystem, the notarization data causing an application program executed bythe first computing system to modify local reference data in accordancewith the notarization data.
 16. An apparatus, comprising: a memorystoring instructions; a communications interface; and at least oneprocessor coupled to the communications interface and the memory, the atleast one processor being configured to execute the instructions to:transmit, via the communications interface, a request to modify anelement of local reference data to a first computing system, the firstcomputing system performing operations that approve the requestedmodification based on a notarization criterion maintained within anelement of a first distributed ledger, and that record notarization datacharacterizing the approved modification within an additional element ofthe first distributed ledger; receive the notarization data from thefirst computing system via the communications interface; and modify aportion of the local reference data in accordance with the notarizationdata.
 17. The apparatus of claim 16, wherein: the local reference datacomprises a local replication of reference data, the reference databeing maintained at a second computing system in communication with thefirst computing system; and the at least one processor is furtherconfigured to receive at least a portion of the local reference datafrom the first computing system via the communications interface, and tostore the local reference data within the memory.
 18. The apparatus ofclaim 16, wherein the at least one processor is further configured toexecute the instructions to: receive, via the communications interface,information associated with the requested modification and a firstdigital signature from a device; based on a validation of the firstdigital signature, perform operations that generate the request andapply a second digital signature to the request using a correspondingprivate cryptographic key, the generated request comprising at least aportion of the received information and the digital signature; transmitthe request and the second digital signature to the first computingsystem via the communications device.
 19. The apparatus of claim 18,wherein the at least one processor is further configured to execute theinstructions to: load, from the memory, a replication time associatedwith the local reference data; and when a temporal difference between acurrent time and the replication time fails to exceed a thresholdtemporal interval, transmit the request and the second digital signatureto the first computing system via the communications device.
 20. Theapparatus of claim 16, wherein the at least one processor is furtherconfigured to execute the instructions to: perform operations thatrecord data characterizing the requested modification to the localreference data within an element of a second distributed ledger; performadditional operations that record at least a portion of the notarizationdata within an additional element of the second distributed ledger; andstore the second distributed ledger within at a portion of the memory.